Kit Wai Chan - Fotolia


Boost AWS availability with a microservice architecture

Some large-scale enterprises are deploying microservice architectures on top of AWS. What advantages could this move offer your enterprise?

Microservices are an emerging software architecture used to divide large monolithic applications and services into dozens of supporting microservices. A microservice strategy makes it easier to scale individual components, instead of the entire application stack, to meet service-level agreements.

With large applications, adding more users means provisioning larger Elastic Compute Cloud (EC2) instance sizes, even though only some of functionality is growing. The net result is that enterprises only pay for the EC2 instances needed to support the demands of overtaxed microservices. A few large-scale enterprises such as Netflix and Nike are deploying a microservice architecture on top of Amazon Web Services (AWS) to improve agility and scale applications at a lower cost. Netflix has more than 500 microservices being designed across 30 engineering teams.

Choosing between containers and code

A microservice architecture is a way to design applications as suites of independently deployable services. There is no precise definition of the concept, but these architectures tend to be organized around business capability, automated deployment and decentralized governance.

Many enterprises are using containerization technology such as Docker on top of the Amazon EC2 Container Service, making it possible to run applications on a managed cluster of EC2 instances. This reduces the need to install, operate and scale the cluster management infrastructure needed to deploy individual microservice components. But containers are not necessarily designed to implement microservices.

New services like AWS Lambda make it possible to deploy a microservice architecture without containers or VMs. Lambda runs code in response to events and manages compute resources, making it easier to build collections of microservices that respond to events or traffic. Developers can spin up new services in Lambda within milliseconds of an event such as a Website click; billing is metered in 100 millisecond increments.

Easing the transition to a microservice architecture

There are a number of best practices that enterprise architects can follow to get the most out of a transition to microservices, including properly selecting storage, rethinking traditional IT silos, creating boundaries between microservice components, and more.

Choose the best data store for each service. One of the benefits of a microservice architecture is that individual microservices are loosely coupled. This allows developers to choose the development language and data store that's best suited for a particular microservice, instead of relying on a single database for all the components.

Replace silos with microservice teams. For a microservice architecture to work, software development teams must collaborate and scale. According to Conway's Law, the interface structure of a software system will reflect the social structure of the organization that produced it. To switch to a microservice architecture, companies need to organize staff into product teams and use DevOps methodologies.

Traditional software teams separate groups into silos that don't overlap with development, QA and production teams. "You want a small team that is in charge of its microservice -- from concept through design, coding, testing and deployment -- and then, presumably, bug fixes and updates," said Owen Garrett, head of products for Nginx, an application delivery platform vendor.

Treat microservices like Web apps. It's necessary to create strong boundaries between microservice components. Treating microservices like Web apps means that separate development teams don't require an intimate understanding of the inner workings of different microservices. Instead, microservices need an API for the functions they can perform.

"You don't expose any of the internals of your microservices," Garrett added. "The dev teams for other microservices shouldn't need to need to know anything about the way microservices represent or store data internally to make requests to it." This approach makes it possible to change the microservice as needed, as long as the API presented to other microservices is not broken.

Use declarative contracts. Program using the declarative nature of service contracts, as opposed to implementing procedures for how to use other services. It's easier to use an abstracted method to run requirements; an interpretive set of steps will make the process more static. This means developers can implement applications through policies to give the infrastructure instructions.

Instead of coding EC2 semantics, for example, developers can apply policies to move data into AWS products. Include declarative artifacts into the container that houses the microservice or embed them into Lambda code that's used to communicate with AWS products.

Use the OODA loop. Because separate teams can craft individual microservices, organizations must ensure the software development team is working toward a common goal. Using Netflix's Observe, Orient, Decide, Act (OODA) loop can be helpful.

In an OODA loop, observe involves examining the current status of the code base for opportunities to innovate; orient involves analyzing metrics to understand the phenomena that has been observed; decide is the process of developing and executing a project plan; and act is the process of testing a solution and putting it into production.

Microservice tradeoffs

There are a variety of tradeoffs involved in making microservices work in practice. Breaking apart data sources can complicate data management because separate storage systems can more easily get out of sync or become inconsistent. Foreign keys also can change unexpectedly. A good practice is to add a tool that runs in the background and performs master data management to find and fix inconsistencies.

Microservice architecture might not be the best approach for all projects. There seems to be a general consensus that a monolithic model is fine for smaller development groups; the extra overhead of a microservice architecture might not be worth it for small companies either. "But when you get to the size where the monolith doesn't work anymore, you have to change models in midstream," said Nginx's Garrett. "Building in some conceptual microservices features from the beginning will make the transition less painful.

Next Steps

Getting to the bottom of a microservice architecture

How do you define microservices?

Find out how well you know microservice architectures

Dig Deeper on AWS architecture and design