In today’s hyper-competitive market, the optimal path for your business should be obvious. In other words, you want to always be with or ahead of the curve. That means your developers and your IT staff will always be learning new technology and best practices. As you learn new skills and adopt new software stacks, you’ll find a number of decisions must be made.
One important decision you’ll be faced with is whether to go with microservices architecture or monolithic architecture. Make the right choice for your company and you’ll experience serious gains. Make the wrong choice and you’ll find yourself in a constant uphill battle to keep your data center running smoothly.
So, what are these architectures? Let’s examine them and see which one might be right for you.
We start with monolithic because it’s the simplest to understand. Why? Because monolithic architecture has been around for a very long time. In fact, monolithic applications are what most people understand as “software.”
Simply put, a monolithic application is one that is built as a single unit, though that doesn’t necessarily mean everything is included to make that application run. Let’s break it down so we can better understand what’s going on.
Yes, there are applications that are installed as standalone clients. Take, for instance, an office suite like LibreOffice. This application doesn’t depend on any third-party or external software or services to run. It’s all run on the local client machine.
On the other hand, the WordPress blogging platform requires the following to function:
- A database server
- A server-side application
- A client-side user interface
Each of those components is monolithic and works together to create the whole.
Confused? Let’s simplify it by looking at it from a developer’s perspective.
Let’s say your company has deployed a monolithic Content Management System that was built in-house. This system includes a database, a server-side application, and a client-side user interface. It runs smoothly and your staff depends upon it every day.
At some point, however, your developers want to add new functionality to the server-side component. In order to do that, the developers will have to rebuild and redeploy the entire server-side application. Although the end result might be worth the effort, it takes considerable time to go through the entire development process (design, development, Q&A testing, and deployment).
Now let’s examine the microservice architecture. Whereas a monolithic application is contained within a single unit, microservices break it down into a collection of much smaller, independent units. Each of these units functions to serve up every application service that then combines as a unified whole.
One of the best examples of microservice architecture is containers.
You could deploy an NGINX server as a monolithic service. Install NGINX on a Linux server and you’re ready to serve up your websites. You could add a database into the mix by installing MariaDB. There are, however, two big problems with such a deployment.
First, if you want to upgrade your web server, you must upgrade each component as a whole—the web server and the database. Second, this type of deployment might not be capable of scaling to meet enterprise needs.
The other route would be to deploy that web server as a collection of microservices, via containers. You could deploy a Kubernetes pod containing the NGINX web server, a pod containing the database, and then connect them together with a network service and a storage volume to house data.
When you need to scale the deployment up, Kubernetes can automatically deploy more NGINX and MariaDB containers to the cluster.
Beyond scalability, one of the best features of the microservices architecture is that, should one of the services fail, another will be deployed in its place. So failover is built-in. And because all of your components are deployed independently, the prospect of updating is much smoother. This is especially so with containers, where upgrade-induced downtime is almost non-existent.
Which is best for your company?
This can be answered pretty simply:
- If your company needs high scalability, failover, and reliability, you need to be using a microservices architecture.
- If your company mostly requires client-based tools (that are installed on desktops) or you’re not considered with enterprise-level scale-out, monolithic architecture is the way to go.
This comes with a caveat. Microservice architecture isn’t all that easy to deploy. Kubernetes is challenging on just about every conceivable level. So if you are interested in microservices architecture, you must make sure you have developers and IT admins up to the task, otherwise, you’ll find yourself in a constant state of problem-solving.
Also, in order to have a successful microservices deployment, you need the resources. To really take advantage of the scalability of microservices, you need a data center with enough horsepower to handle that architecture. Most often, this means deploying to a third-party cloud host, such as Amazon AWS, Google Cloud, Linode, Rackspace, or Microsoft Azure. Unless you have a seriously impressive on-premise data center, you’re not going to reach the levels of scale that you would with one of those hosts.
In the end, the choice is yours. But for most businesses looking to grow well beyond anything they’ve ever achieved, microservices are the way forward.