The new-school system architecture: Microservices

Microservice architecture has emerged as a solution to the challenges of developing, testing, and scaling complex applications. While the benefits of its predecessor, Service-oriented Architecture (SOA), have been appreciated for many years, the complexity of creating and maintaining a distributed architecture has prevented SOA from gaining widespread adoption outside of large organizations. Two recent technological advances, cloud deployment and containerization, have brought this methodology within reach of smaller teams that do not have dedicated Operations staff. Microservice architecture promises a new way of building systems that is cheaper, faster and more resilient.

What is microservice architecture?

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms

Martin Fowler, Microservices

Servers

In a typical web application, all of the features are contained in a single codebase (sometimes referred to derisively as a “monolith”). In a microservice architecture the codebase is broken apart into separate components, called “microservices”, that encapsulate a single business need. Examples of common microservices include serving a web page, authenticating a user, or sending an email. By separating each business need into a microservice you are able to ensure that issues that arise in one area of your application do not affect the system as a whole.

Communication

Each microservice communicates with other services using standard HTTP connections. Using HTTP allows developers to easily develop microservices using their existing toolset and it also makes it very easy to connect to and/or wrap 3rd-party API’s.

There is, however, an extra communication challenge when using a microservice architecture — a very complicated challenge, in fact. Each microservice must be able to find and communicate with the other microservices that comprise your application, and, at scale, there may be many instances of each microservice. To solve this challenge, microservices need to announce that they exist and then find the other microservices that they require. This is called “service discovery”, and there are currently a number of innovative projects working on the best way to solve it.

Data Persistence

A microservice architecture works best when each microservice is stateless — each request to a microservice completely independent of the requests that came before it. Is this allows for maximum flexibility when it comes time to scale. Furthermore, each microservice is responsible for maintaining its own data. This eliminates the database as a ‘single point of failure’.

What are the advantages of a microservice architecture?

Microservices are independent

Whether you are an single developer or part of a large organization, each change to your codebase carries with it the risk of unintended consequences. As the codebase grows that risk becomes an impediment to rapidly deploying new features.

Microservices architecture allows each microservice to be developed, maintained and scaled independently. When this architecture is coupled with version control (git) and automated cloud deployment, new features can be added and removed without threatening the stability of the application. New features can be written in new languages; new data can be stored in new formats. Microservices can free your organization from the technological burdens of its past.

Business-focused and team-owned

Microservice architecture is not simply a technical choice — when properly implemented it should align with and facilitate the goals of your organization. From a business perspective your customer-facing website is quite different from your payment provider interface — it has a different audience, different metrics, different testing strategies, and different timelines. A microservice architecture allows these functions to evolve in parallel with a minimal amount of developer coordination and planning.

In larger organizations, this separation can also extend to your org chart — each microservice can be maintained by a separate team. This reduces communication and management overhead and allows the team to manage their entire stack, from the UI to the business logic to the database. When your developers are encouraged to take ownership of a problem, and also empowered to find their own solutions, they’ll be happier and more productive.

Designed for failure

Generally speaking, most systems are built with the goal of stability and system monitoring is focused on detecting activity that deviates from the expected behavior. But what happens when behavior is not predictable in advance? How do you design a system when you are not sure how the system will need to evolve?

With the rise of agile development, systems focused on stability may in fact be an anti-pattern. Microservice architecture take a different approach — expect failure, and design for it. No one embodies this mindset better than Netflix and their awesomely-named open-source project Chaos Monkey — a service explicitly designed to crash other services. By designing for failure — and inducing it — a more resilient system emerges, one that can handle even unexpected issues.

Automated

By creating microservices that are independent and stateless, the issues of provisioning and scaling can be almost completely automated. Through the use of service-discovery, each microservice will detect and connect with other microservices as they become available. Integrated health-checks ensure that slow or unresponsive microservices will be shut down, and a more responsive instance can be rapidly provisioned to replace it. Errors or bottle-necks can be isolated and avoided by other microservices, and all of this can happen automatically.

With the technical steps fully automated, you can now administer your system using business-focused thresholds — make this microservice’s response time as fast as possible up to $X dollars per hour, or do whatever it takes to keep the response time below 15ms, etc. — let your system do the grunt work of determining how to accomplish these tasks.

I’m sold — so what’s the problem?

…building, deploying and maintaining distributed applications is a highly technical feat. [ ]… it requires a new toolkit that is central to solving the coordination and orchestration challenges of running systems that span across multiple machines, data centers and time zones.

Lenny Pruss, Warehouse Computing and the Evolution of the Datacenter

Enter LSQ

And that’s why we’re building LSQ — a next-generation development tool and PaaS that will allow independent developers and small teams to take advantage of the exciting new techniques that have emerged during the past few years.

The LSQ Products

LSQ is the first tool to allow you to quickly build robust applications using a microservice architecture. Follow the links below to learn more about the LSQ products:

LSQ Local — Run and monitor multiple microservices using our free desktop application. Available now!

LSQ Connect (coming soon) — Share and test microservice applications

LSQ Cloud (coming soon) — intelligent microservice deployment