As a software engineer, if you stick around long enough, you run into new paradigms of software design and architecture. Once in a great while, you run into some real game changers.
When the internet burst on the scene in the mid 1990s, it opened up a whole new world of internet application development, which would eventually replace client desktop application development in the enterprise.
When XML first came out, it opened up a new data exchange format that allowed for completely different systems, applications and tech stacks to communicate to each other via web services. So now an enterprise component that happened to be written in Java could communicate to a different enterprise component written in Microsoft’s Visual Basic.
When Steve Jobs took the stage and introduced the iPhone, it took mobile phone application development into the mainstream and now mobile apps are becoming a crucial cornerstone in business enterprises.
There’s a new application design architecture that I’m beginning to hear about, even within my own company.
It’s called microservices architecture and it changes the way we software engineers think about the way we design and build applications.
Traditional enterprise applications are written in what is referred to as a “monolithic style”. If you remember the dark, foreboding giant monolith slab from the movie “2001: A Space Odyssey”, it’s what monolithic style app development is trying to convey.
When you run a monolithic business application, everything is self contained within inside the application.
A typical business application is divided up into 3 layers (or tiers).
1. UI layer
2. Business logic layer
3. Data layer
The UI layer is your presentation layer. It’s what the customer of your application visually sees. If it’s a web based application, it’s all the HTML and CSS style sheet files that make up the user interface screens. If it’s a mobile application, it’s all the user defined screens that would show up on your mobile phone when you launch the application.
The Business logic layer handles all the routing and business logic of your application. It also acts as the gateway between your front end UI layer and the backend data layer services.
The Data layer is where all the data for your application is located. It’s typically stored in some sort of relational or document based database.
The reason behind splitting up an application into these layers is what’s referred to as “separation of concerns”. Each layer is isolated from the other layers.
The UI layer only contains UI related code. The business logic layer only contains code that contains business logic related code. The data layer only contains data related code.
That way, if you ever have to change something like, say, something in the user interface, you only have to change code in the UI layer, and not worry about the business or data layers getting affected by the UI layer. Or you can change something in the business logic layer and not worry about your changes affecting the UI or data layers.
Separation of concerns is a great way to avoid duplication of code and minimizing the danger of changing it, when the need arises.
However, there still remains a problem.
Changing any of the three layers, especially the business layer, often requires a redeployment of the entire application.
That is what is meant by a “monolithic” application. Each of the layers are all running inside the same application process. In a sense, each of the layers are “tightly coupled” within the same application.
For instance, say you have a business application which connects to some sort of back end database.
Say you have a button you can click on in the user interface, that pulls back the latest set of database records from the data layer and displays them to the screen.
You would have some sort of code that would look something like this:
public void RetrieveResultset(string query) {
var dataServiceLibrary = new DataServiceLibrary();
var dataResults = dataServiceLibrary.GetData(query);
return dataResults;
}
The DataServiceLibrary is typically a separate class library that handles the communication to the data layer. It can be reused in other sections of the application whenever access to the data layer is needed.
And that’s what class libraries are all about…they’re REUSABLE little nuggets of code that you can use over and over, so you avoid having to reinvent the wheel, everytime you need data access.
The problem is when you have to CHANGE that DataServiceLibrary class library. It lives within the context of the application it lives in. Therefore, in order to change or add new functionality to the library, you must change the code, and redeploy the library along with the application.
Now if the application is fairly small, it’s not that big of a deal. But say you’re in a business enterprise environment and that class library is getting used by many different applications. Now you have to deal with the headache of redeploying that class library with every application that references it.
Using microservices instead of local class libraries solves the tight coupling problem that using class libraries entails.
Instead of using a DataServicesLibrary that lives in the same application process as the main application, you use a “microservice” instead.
This microservice lives completely OUTSIDE your main application. It is typically a web service that you communicate with via the HTTP protocol and is REST based … that is, everything the microservice needs for it to run, is part of the request to the service.
Now anytime you need to change the microservice, it is truly INDEPENDENT of any application that needs to consume it. If you need to CHANGE the microservice, you can change it and any external application that depends on that microservice will not be affected by the change.
Another advantage of the microservice architecture is the microservice can be written in any language/tech stack framework you wish. It doesn’t have to be written in the same language/tech stack of the consuming application.
If you work at a company like mine, that uses many different tech stacks and languages, you can leverage all that expertise via a microservices architecture. Microservices can be written in any language/framework because the actual exposed endpoint is through a public HTTP endpoint which any modern language can communicate with.
As with everything you do in software development, there are, however, tradeoffs to everything you do and use, and microservices are no exception.
If your microservice is an HTTP based service, your potential failure point becomes HTTP. If the microservice becomes unavailable because of, say, network problems, you’ve basically crippled any application consuming that microservice.
There are, of course ways, to minimize the risk…having redundant servers that host your microservice, and using a load balancer to route HTTP requests to your microservice, when one of the servers that is hosting your microservice, fails.
The other unavoidable downside to microservices is speed. A class library call that lives inside the same process as the application runs much quicker than an external HTTP call to a microservice.
Software engineering is all about tradeoffs. Microservices is simply another tool in the toolbox. You need to weigh the benefits of the loosely coupled architecture of microservices against the potential downsides of speed and the unavailability of the microservice, when things go wrong.
