What you need to know about moving monoliths to microservices

There are many benefits to the "monolithic" application model -- especially at the beginning of a project -- but monoliths can become unwieldy over time, limiting companies’ ability to move quickly and flexibly in today’s dynamic business environment.

To overcome this and other issues, companies like Amazon, eBay and Netflix are leveraging microservice architectures. The microservices model has been defined by Martin Fowler, author, software developer and an early supporter of microservices as "an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API."

Fowler notes that "these services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."

While the concept of microservices is not new, it has become an essential part of the development process in today’s dynamically changing business environment. Each service has distinct boundaries and are interfaced through an API. Microservices enable a level of modularity that renders individual services quicker to develop, test and deploy and, as a result, developers are able to work with services that are much easier to understand and maintain.

One of the noted benefits from the microservice model is the ability for developers to focus on a single service rather than an entire monolithic application. This results in developers not being hindered by the technology or technologies used to build the original monolith, and they can choose the technology -- and iterative timetable -- that works best for the task at hand. Similarly, every service has its own database schema, which allows developers to use the type of database that is best for the service’s needs.

Here are eight things you need to know about moving from monoliths to microservices.

1. Microservices are modular

In the microservices model, applications are split into a small set of interconnected services based on business capability. Each service implements a set of distinct features -- in effect, serving as a mini-application with its own business logic, adapters and even database schema. Services can be grouped together in different ways, with the sum of their parts serving as new products.

2. Microservices are not a new idea

With continuous delivery & integration, containers and DevOps, the pace of innovation on the web has increased dramatically and the concept of microservices is more important than ever. Each service has a well-defined boundary in the form of a RESTful, RPC or message-driven API. The model enforces a level of modularity that makes individual services much faster to develop, and much easier to understand and maintain.

3. Internal Security of Your Microservices is Paramount

Organizations should not forget the internal security of a microservices application. It is worthwhile to remain cognizant of the security threats brought on by other components in the application -- even if they can be trusted now, there is no telling how the client base for the application will grow in the future.

A good first step is to standardize on TLS for all internal communications and then build certificate validation for both clients and servers into the architecture from the start. Organizations can experience impact on performance by doing this so accelerating proxies like NGINX can minimize impact.

Additionally, a unique identifier for each transaction using something like OpenTracing is invaluable when logging and auditing transactions.

4. Split The Front End From The Back End

With most monolithic applications, there is a clean separation between the presentation logic on one side and the business and data-access logic on the other, including an API that can act as a seam. "Splitting" the application along this seam creates two smaller, more manageable applications.

5. Smaller Services Can Mean Simpler Development

The microservices model makes it easier for teams of developers to focus on a single service rather than the entire monolithic application. Developers are not stuck with the technology that was used previously to build the original monolith, and they can choose the technology that works best for the task at hand.

Organizations can turn existing modules into stand-alone microservices. Every time a developer extracts a module and turns it into a service, the existing monolith shrinks. The more modules converted, the less problems a complex monolith will cause.

6. Each Service Has Its Own Database Schema

This goes against the idea of an enterprise-wide data model, but enables developers to use the type of database that is best suited to the service’s needs. This is known as the polyglot persistence architecture, which is in essence, the idea of using multiple data storage technologies, which are chosen based on how the data is used by individual applications.

7. Microservices have a larger attack surface than monoliths

Microservices have a larger attack surface compared to monoliths so it is important to recognize security differences and act accordingly.

Microservices communicate between the different services. They all used to live on the same server but microservices are now spread out on different servers, communicating over a network. If someone compromises the network and installs a probe, for example, they’ll be able to see a lot of traffic with potentially sensitive information in it. One way to protect your organization from this is to use SSL for communication between microservices, which NGINX’s fabric model accomplishes very efficiently.

No matter what the company size or industry, if you are a developer today, you are likely working on one monolithic application or another -- struggling to update, test and deploy what has become an overgrown, bloated blob of an app. As business demands grow more complex, so, too, do many of the applications used to drive and support business. And the more complex the application, the less sense it makes in a monolithic model. Microservices can help companies more effectively manage their monolithic applications. And, over time, once companies have converted enough modules to microservices, the monolith will cease to be an issue.

Chris Stetson, chief architect, Microservices Engineering, NGINX.

Published under license from ITProPortal.com, a Future plc Publication. All rights reserved.

Photo Credit: ProStockStudio/Shutterstock