Welcome!

Microservices Expo Authors: Liz McMillan, Elizabeth White, Zakia Bouachraoui, Jason Bloomberg, Pat Romanski

Related Topics: Microservices Expo, Java IoT, Containers Expo Blog, Agile Computing, @CloudExpo, SDN Journal

Microservices Expo: Blog Feed Post

API Management for Obamacare and Healthcare.gov

For the uninitiated API here is a programming interface that represents just the server side of the Healthcare.gov functionality

It's not every day that you hear about a software project on public media, but NPR and other public outlets are covering the troubled rollout of the Healthcare.gov website nearly hourly. As a software professional, the problems I was hearing about are common in a large software project, where multiple pieces of the final product are built independently and then integrated together at the end.

API Management for Obamacare

We are in the Post-Website Era. APIs Can Help.

The practical problem here is that it is too easy for disparate contractors working on just their piece to even understand how the whole will fit together. In fact, the nature of computing and programming relies on this to some extent: Treating individual components as modules assumes a certain amount of ignorance on how inputs to one particular module are derived and where outputs are used in other parts of the system. This means developers can focus on making their piece meets the appropriate functional and non-functional requirements which makes them "cogs in the machine." All of them are performing essential functions, but can't see the forest for the trees. They can't step outside of their own cog.

API-Management-Cog-In-The-Machine

Multiple contractors can be a cog in the machine

This type of result can actually be predicted. In 1968, Computer Scientist Walter Conway described an assertion later known as Conway's Law:  "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

This implies that the resultant software system will inherit communication (or non-communication) properties of the organization that designed it. In this case if we had dozens of private contractors with inadequate communication, you will end up with a system not properly tested end-to-end, which is exactly what happened here. Further, testing  that occurs only ‘at the end' of a software project is reminiscent of a waterfall software model, which is great for designing nuclear missiles, but extremely bad for designing a dynamic, highly scalable software system with heavy user-interface and usability requirements like Healthcare.gov.

So what happened with Healthcare.gov? Reuters' technology review suggests that the core design problem with the Healthcare.gov website was not the scalability of the server-side architecture, but the sheer amount of client logic pushed down to the browser, citing 92 separate files and plugins, including over 50 JavaScript files. By design, this means that your experience on Healthcare.gov is not just a function of how the website was designed, but also the client processor power, memory and client side factors, not to mention your available network bandwidth and round-trip latency. In short, the current architecture of the website appears to place too much work, and consequently blame, on the client. This also means the website may work better for some if you have a beefier client system.

Before the public fiasco, I mused that an Obamacare API and an API Management architecture might be a good thing based on lowered expectations of a smooth rollout of Healthcare.gov. Now I think it's more than a good thing, API Management just might be a savior. How? Rather than build a user interface, the government should have made an API and had the contractors compete to build the best interface. Here, the API could be a RESTful API launched as an open API allowing anyone to take a crack at using it to make the best possible experience for the user. This architecture cleanly separates the concerns - the government runs the server side and manages the API, data and transactional services and someone else writes the client piece.

For the uninitiated, API here is a programming interface that represents just the server side of the Healthcare.gov functionality. The API would consist of a set of interfaces that provide all of the necessary data and transaction methods to allow a client consumer to purchase healthcare through the exchange. It could use well-established, highly scalable technologies such as an API Management Gateway for handling traffic and API Catalog and Developer on-boarding portal for on-boarding public and internal developers. For reference, Intel's API gateway can handle over 18 billion calls per month, per node. Moreover, the current technology offerings for a developer catalog and portal would effectively allow internal developers working at the government to compete with external developers to build the best user interface.

The best part about this approach is that the government would not have to worry about the user interface and client experience. This could be left up to people who know how to design great user interfaces and would open the way to making the Healthcare.gov application available not just through a browser, but with an HTML5 or native mobile application. This is a true win-win. The government won't be blamed for a bad website and consumers get the best possible experience.

API Management for Healthcare.gov

 

The post API Management for Obamacare and Healthcare.gov appeared first on Application Security.

Read the original blog entry...

More Stories By Application Security

This blog references our expert posts on application and web services security.

Microservices Articles
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. In his session at 18th Cloud Expo, Gordon Haff, senior cloud strategy marketing and evangelism manager at Red Hat, will discuss how today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of rec...
The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids and Smart Cities, the Industrial Internet, and more. Cool platforms like Arduino, Raspberry Pi, Intel's Galileo and Edison, and a diverse world of sensors are making the IoT a great toy box for developers in all these areas. In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists discussed what things are the most important, which will have the most profound e...
If your cloud deployment is on AWS with predictable workloads, Reserved Instances (RIs) can provide your business substantial savings compared to pay-as-you-go, on-demand services alone. Continuous monitoring of cloud usage and active management of Elastic Compute Cloud (EC2), Relational Database Service (RDS) and ElastiCache through RIs will optimize performance. Learn how you can purchase and apply the right Reserved Instances for optimum utilization and increased ROI.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...
Consumer-driven contracts are an essential part of a mature microservice testing portfolio enabling independent service deployments. In this presentation we'll provide an overview of the tools, patterns and pain points we've seen when implementing contract testing in large development organizations.
In his session at 19th Cloud Expo, Claude Remillard, Principal Program Manager in Developer Division at Microsoft, contrasted how his team used config as code and immutable patterns for continuous delivery of microservices and apps to the cloud. He showed how the immutable patterns helps developers do away with most of the complexity of config as code-enabling scenarios such as rollback, zero downtime upgrades with far greater simplicity. He also demoed building immutable pipelines in the cloud ...
You have great SaaS business app ideas. You want to turn your idea quickly into a functional and engaging proof of concept. You need to be able to modify it to meet customers' needs, and you need to deliver a complete and secure SaaS application. How could you achieve all the above and yet avoid unforeseen IT requirements that add unnecessary cost and complexity? You also want your app to be responsive in any device at any time. In his session at 19th Cloud Expo, Mark Allen, General Manager of...