Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

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

This was last published in May 2015

Dig Deeper on AWS architecture and design

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

7 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Is your company interested in microservices? Why or why not?
Cancel

i'am agree if my companie went to invested in microsoft sevice for thecnology evolution
Cancel
Yes I agree with architecting and implementing a micro service architecture for large applications for better maintainability, resilience, disaster recovery & monitoring. We used to do this even in the times of AWS AMI Auto Scaling before docker even started to exist.
Cancel
Interesting stuff, but I think that (as happens with a lot of new technologies), the idea of microservices suffers from a general unfamiliarity across enterprises. The more you can learn, the more business decision makers will realize the power of this app dev approach.

Here's another article from Lawton explaining how microservices enables Agile development to classic SOA situations:
http://searchcloudapplications.techtarget.com/feature/How-microservices-bring-agility-to-SOA

A basic discussion of microservice architecture:
http://searchsoa.techtarget.com/answer/Microservices-architecture-101-What-the-heck-is-it

And a discussion about ESBs vs. microservices:
http://searchsoa.techtarget.com/video/Moving-away-from-ESBs-to-microservices

Cancel
We are interested in microservices for many reasons, including the loose coupling it allows to deploy and maintain the components, and how we can leverage containers to assist with that.
Cancel
Yes, it is. Currently trying to find out how we can mange it with AWS.
Cancel
One aspect to keep in mind with respect to the trade-offs associated with moving to microservices is the impact that move has on testing activities. Testing Strategies in a Microservice Architecture addresses this nicely.
Cancel

-ADS BY GOOGLE

SearchCloudApplications

TheServerSide

SearchSoftwareQuality

SearchCloudComputing

Close