Why do we need microservices? The same hype was made over service-oriented architecture a decade ago and despite all expectations, 90 percent of all software architectures didn’t adopt service-oriented architecture (SOA) by 2009.
What changed?
As we speak, there are over four billion people connected online. Over 30 billion IoT devices are shuttling information back and forth to over 25 million applications from every corner of the world. There is too much activity coming from too many different locations to funnel it through a single monolith taxing a single server.
The scale and speed of today’s digital world demands distributed architectures. Where SOA was a luxury then, microservices are a necessity now.
So What are Microservices?
Microservices takes an application and splits it up into functions called services. Each service can have its own environment, database and place to run. In a monolith, if a server goes down, your application goes down. And in some cases, your entire organization can go down. This is true even if you are running on multiple servers. A monolith is typically modeled as a single application, but multiple applications that are co-dependent on one another are just as dangerous. A single failure will take the whole system down.
When your system is composed of independent microservices, one function can go offline without any hiccups. It’s like a four-engine jet experiencing a blowout in the far-left wing — the flight will continue and nobody is the wiser. It isn’t ideal, but the system is able to work in this mode and continue normal operations.
In order for this architecture to work optimally, each service must be fully independent of one other. They can signal to each other when or even how they should function, but these services cannot be dependent on one another at all. Any type of dependency can result in a multi-service crash if just one of the services stops working. And it can get even worse — A slow-down in one service will cause traffic jams (and eventually total failure) in others, if they are directly dependent on the slow service.
Microservices Runs Like a Good Restaurant
At all the best restaurants, the host has a system to manage reservations, walk-ins and customer placement. The bartender, who serves guests as they wait for their seat, is famous for knowing what his customers like to drink. The waiter has his own notepad to write diner’s orders. The kitchen has an order wheel to receive the orders and start preparing them, and the cashier has a register.
What if we gave this restaurant a microservices architecture? The host would use a nonrelational database to manage the reservation system. Updates can be made as one party comes with more people, and deletes can happen upon cancellations. Alerts can be made once people are done dining and the table is available.
In a microservices architecture, you have the flexibility to choose the best database for each service.
The bartender can use a graph database to match the right drink to the customer. Based on the customers that are walking up to the bar waiting to be seated, the service can call up their order history and recommend the best cocktails. Once seated, the waiter can use a document database to take the orders, especially if they have to be customized for specific diners’ tastes and needs or if the diner wants to see images of the meal before ordering. Once done, an ETL can take the order and hit the kitchen, telling them to get started and what to prepare. Using a key-value persistence model, the kitchen will see the next order to prepare and get to it.
Because each step in the dining process is an independent service that doesn’t need other services to operate, the customer benefits from the added efficiency of restaurant staff being able to take on each other’s tasks. Once the dining experience is over, the satisfied customers can pay the cashier by running their register on a relational database.
SQL vs NoSQL: Enemies, a Love Story
A monolith application typically limits you to one database and one type of persistence. In a microservices architecture, you have the flexibility to choose the best database for each service. Some functions need the rigidity of a hard schema that a relational database demands, and others require the flexibility inherent in a nonrelational option.
According to Gartner, 70 percent of databases are relational, and per IDC, 90 percent of all new applications will use microservices as their architecture. Even if the default choice remains relational, there will be a lot more room for specific functions to be assigned to boutique nonrelational databases that can give your overall application a polyglot persistence. Thus ends the Coke vs Pepsi challenge of which to choose. SQL and NoSQL have become a tasty cocktail of an everything-you-need data system that will conquer the world.
What Is So Special about Non-Relational Databases?
The big benefit of nonrelational databases is distributed data. After only 40 years of a single point server, relational has begun to dip its toe into distributed architectures. It’s a broken model because you are adding complexity upon complexity. A relational database will answer queries by taking data from multiple tables, and then putting it all together. If you distribute this, it becomes even more complex. Put it inside a microservices architecture and you have three levels of increasing complexity.
Ouch.
A nonrelational database like a document model will put everything you need in one spot, eliminating the need for tables. This makes things a lot simpler, and easy to connect with a distributed topology. Right out of the gate, nonrelational simplifies things for a microservices architecture.
Add into the mix that nonrelational databases are lightweight. They can be simple to use, especially the ones that have flexible schemas or no schema at all.
You can set them up faster, eliminating a level of complexity to your new architecture. Services are also distributed, and a nonrelational model can support that with a distributed database that can sit under any service you like. It adds to the durability of your application. A microservices application will often replicate the same service to be a backup just in case the service goes down. You can scale out a distributed database so all the replicas of a service access the same database and can scale out in tandem. With instant replication, the database on standby is as up-to-date as the one that went offline giving you continuous deployment throughout your entire microservices application stack.
Nonrelational databases also have low to no overhead. For each instance, you can minimize pain, friction, and especially complexity. The best database solutions are the silent ones that can optimize themselves to new configuration environments and don’t need a DBA to babysit them. DBAs will be a lot busier in this new architecture. Anything that eases their new workload is welcome. This is important for a microservices environment where you’ll be deploying a LOT and often.
Most of all, microservices are built for speed. NoSQL enables most services to get set up quickly, scale-out fast, and create additional data nodes where you can test without touching the persistence layer. All of this is aimed at keeping your release cycle faster than ever.
Conclusions
Microservices is the new incumbent software architecture. It lives on flexibility, being distributed and high availability. The mindset of a microservices architecture goes hand in hand with the dynamic thinking of the nonrelational data approach. 2018 saw developers coding in a microservices architecture opt for NoSQL more frequently. As unstructured data continues to grow and more applications are launched from cloud platforms to support optimal use of resources to your application layer, the growing attraction of nonrelational thinking to the cutting-edge developer will continue.
Feature image via Pixabay.
