The traditional method for developing new software systems is through the use of a monolithic architecture. A monolithic application is a software that was built as a single unit. All of the code exists within a single codebase and all of its modules are interconnected. However, more and more developers are beginning to abandon the monolithic architecture in favor of a microservices architecture.
A software that’s developed using a microservices architecture is built out of smaller units that work together to function as a whole. The application is divided into services that are individually developed and are maintained separately instead of being developed as a single unit. One of the reasons developers prefer the microservices architecture is due to the flexibility it provides, both during the development of the app and after its deployment. In fact, microservices architecture solves many of the challenges developers typically deal with when developing monolithic applications.
Microservices architecture isn’t as new as you might think. At a software architecture event in 2011, the term microservices was first applied to describe the type of architecture many developers at the time were experimenting with. The term can even be traced back to Dr. Peter Rogers. In 2005, he first brought up the term “micro web services.” However, as an actual concept, the microservices architecture process can be traced back way further. It was born out of a concept that has been evolving over time.
The origin of microservices architecture can be found in the 1980s when Remote Procedure Calls (RCP) was first introduced. RCP was the first major system distribution technology. It was developed by Sun Microsystems as a way to make remote calls transparent for developers. However, developers began facing challenges with processing and memory scalability. As a result, DCE (Distributed Computing Environment) was developed in 1988 and CORBA (Common Object Request Broker Architecture) was developed in 1991. These large machine-crossing systems were built to address the processing and memory expansion issues.
As processors improved and local space addresses became larger, developers began realizing that just because something can be distributed doesn’t mean that it should be. This concept would be described by Martin Fowler as microservices that should be organized around business capabilities. Formerly, small memory space led to chatty interfaces, but now larger memory spaces resulted in systems that were being affected by poor methods distribution. In a system like this, Fowler realized that the networking overhead outweighed the benefits of distribution.
This realization led to the discovery of the Facade pattern outlined in Erich Gamma’s Design Patterns: Elements of Reusable Object Oriented Design. The Facade pattern concerns reducing chattiness by encapsulating the unstructured interfaces of a big system into a single interface that’s more structured. Fowler, along with John Crupi and Kyle Brown, applied the Facade pattern when developing their Session Facade approach. The Session Facade approach was developed to produce a structured interface, making information exchange more proper.
The basic idea of the Facade pattern was to define a specific external API (application programming interface) for a system that is business-driven. The first Session Facades were implemented with EJB (Enterprise JavaBeans) but only worked if used with Java. The lack of language compatibility led to another new approach — SOAP (Simple Object Access Protocol), which would later be called SOA (Service Oriented Architecture).
Microservices architecture is often considered a variant of SOA. Like SOA, microservices allow developers to break down a complex workload into smaller independent components that are more manageable. However, there are a number of differences. Whereas SOA aims to maximize re-usability, makes use of shared data storage, and uses ESB (Enterprise Service Bus) for communication, microservices architecture focuses more on decoupling and bounded context, provides independent data storage, and uses a simple messaging system for communication.
Although many developers are turning to microservices to build their software, there are many architectural styles to consider. Consider what your needs are before making a decision. These are some of the circumstances in which a microservices architecture may be the best option:
If you’re building a large application, it may take a long time to develop and deploy the app in its finished state using monolithic architecture. With microservices architecture, you’ll be able to deliver individual components quickly over time so you don’t necessarily need to deploy your app in a finished state — you can roll out additional features incrementally.
A microservices app is much easier to scale, especially when compared with a monolithic app. Scaling a complex monolithic app requires you to scale the entire system and can take a long time. With a microservices app, you can scale individual services, and can be accomplished much easier and faster. Adding new capabilities to your app will now be much more streamlined.
If you’re using an anemic domain model, then you won’t want to use microservices architecture. However, if you’re planning to build your app with rich domains or with multiple subdomains, then microservices architecture is your best option.
If you have smaller development teams or more limited resources to work with, then a microservices architecture can be a more effective way to develop your app. Your development teams can focus on relatively small scope services one at a time. This will be much more manageable than trying to build the entire application using the monolithic architecture.
Microservices apps are loosely coupled, which makes them independently deployable and easy to maintain. Instead of being organized around the technical capabilities of a product, they are organized around business capabilities. However, these are just some of the more general characteristics of a microservices architecture. The following is a more detailed look into the characteristics of microservices architecture:
Any software application built using the microservices architecture can be broken down into several component services. This allows each component service to be deployed, improved, and then deployed again without affecting the rest of the application. So instead of having to redeploy the entire software to make a minor change, you can just redeploy the service that needs to be tweaked.
Microservices architecture makes use of cross-functional teams that are responsible for building specific products based on individual services. This is different from the traditional monolithic architecture, in which different teams have to focus on specific aspects of development, such as technology layers, databases, or server-side logic to name a few examples. As a result, microservices architecture allows the development of the app to be organized around business capabilities and priorities.
The routing process of a microservices architecture is much more simple. It simply receives requests, processes them, and then responds appropriately. It’s a more simplified routing process, especially when compared to ESBs, which have to utilize high-tech systems for message routing.
Monolithic apps use a single logical database, such as a SQL service that uses a single database with many tables. With microservices architecture, each service manages its own database. This allows for a more decentralized approach to building the software since each service can be deployed, tweaked, redeployed, and managed independently as a result.
Microservices were built to resist failure. Because software built using microservices architecture consists of numerous service components that act independently from one another, the failure of one service won’t affect the others, allowing the app to continue to function despite the failure of one of its components. Conversely, monolithic applications will fail completely as a result of being developed as a single unit.
Because monolithic apps are built as a single unit, they can be difficult to alter or scale. This is especially true if use of the app has grown exponentially or if new types of devices are attempting to access the app. Microservices architecture is an evolutionary design that is easier to change and update should new requirements surface in the future.
Here are some of the advantages of working with a microservices architecture:
The advantages of using microservices architecture to develop your software might make it seem like a no-brainer to do so. However, it’s worth noting that there are a few drawbacks to keep in mind. These include the following:
Running a microservices application requires a tool that allows you to monitor, manage, and scale all of the different components. A few of the different tools that you can implement to orchestrate your microservices include:
Kubernetes is a container-orchestration system that allows you to automate the deployment, managing, and scaling of your microservices application. Although originally designed by Google, it is currently an open-source tool maintained by the Cloud Native Computing Foundation. There are many Kubernetes-based platforms available.
For the non-container components of your app, you can use OpenStack. OpenStack is an open source solution that provides users with a set of software tools that can be used to manage cloud computing platforms. Using OpenStack, your team will be able to deploy virtual machines that can handle different tasks, making it much easier to manage a cloud environment. For example, through the use of OpenStack, horizontal scaling is made easier.
OpenShift is a PaaS (Platform-as-a-Service) Kubernetes container platform developed by Red Hat. Not only does OpenShift include an enterprise-grade Linux OS, it also includes networking, runtime, authentication, authorization, registry, and monitoring solutions. With the use of OpenShift, you’ll be able to automate life-cycle management to help improve security, increase app portability, make cluster operations easier to manage, and improve tailored operations solutions.
Using a PaaS tool, such as OpenShift, will allow your team to focus on writing code by letting them implement easy-to-use open source components (for example, a web server, a continuous integration server, or a database storage engine).
When planning the development of an app, choose an architectural style that will best suit your needs. Instead of automatically opting for the traditional monolithic architecture, we strongly recommend the microservices architecture. Microservices apps provide a number of advantages over monolithic apps and even solve some of the challenges that developers using monolithic architecture tend to face.
The ability to focus on individual services that are independent from one another despite being for the same app provides a huge amount of development and deployment flexibility. Using the microservices architecture, your app will be far more resistant to failure, easier to scale, and much easier to update than monolithic apps.
Do you need assistance with microservices architecture? Contact our experts today!