10 Database ‘Must-Haves’ for Microservices in 2019

Over the last few years, microservices has increasingly become a major market trend, made popular by big names such as Google and Netflix. Looking to 2019, there’s no slowing down. According to IDC, 90 percent of new applications will be built with the new microservices architecture in 2019.

Why is that?

Composed of several independently deployable services, microservices architectures were built to help businesses overcome scalability challenges. Beyond that, they are characterized as being distributed and highly available, making them one of the most agile options out there for developers looking to operate on many different levels at once.

However, as with any new technology, microservices comes with its challenges – most notably how to support it from the back-end. When getting started, it’s important to ask, “how is the database going to run this new architecture?

With multiple different services to address, it’s important to choose the right database characteristics for each. Below are 10 database “must-haves” for any organization looking to successfully incorporate microservices into their IT strategy.

1. Operate with open source

A monolith application can have one database for all functions; however, in a microservices architecture, different services can each operate within its own separate database, which can lead to a dramatic increase cost. An open source database gives users the chance to download a free copy, play with the database and see if it is a right fit before making a major financial commitment. Thanks to the flexibility open source options offer, it’s no wonder Gartner predicts open-source-based database products will account for more than 20 percent of total database revenue by 2020. To ensure success, the key is to make sure the open source option is top quality, reliable, and validated by an industry leader.

2. Make it multi-model

While microservices lets users employ different databases, languages and even different operating systems, why add to the complexity of the system? At the end of the day, it will only cause more headaches. With a multi-model database, one database can do the job of five, running as a Document Database, Key-Value, Graph, Distributed Counters, Time Series and more.

3. …And multi-platform too

With a multi-platform approach, each service team can use whichever platform and language that is best-suited to their service, accelerating their infrastructure innovation and helping to avoid any potential skills gap issues. To accommodate the new flexibility of microservice-based applications, the database must be prepared to understand and work in C#, Node.js, Java, Python, Ruby, Go and more. In today’s market, this is one of the only ways to run multiple services using multiple clients on multiple instances.

4. Simplify set-up

In a microservices environment, there are many microservices, each with attendant databases. To avoid wasting precious time and resources on set-up, the database should be easily downloaded, installed, and secured, taking no more than a matter of minutes.

To maintain maximum simplicity – and avoid piling in a bunch of other add-ons – a database should carry everything it needs to run inside of it from the get-go, such as MapReduce, Full Text Search and Graphical User Interface (GUI). Every additional function it requires increases the level of complexity users have to manage. If the database runs silently, doing everything it needs to do, the rest is a piece of cake.

5. Set and forget it

Can a monolith application that employs 15 developers and two database administrators (DBAs) expect to increase its staff to 150 developers and 20 DBAs because the new version now runs 10 microservices? Assuming IT departments won’t be budgeted more money to do the same project, it’s unlikely. As a result, the DBA now has to know the ins and outs of multiple databases without an increase in staff. As such, the database must require as little overhead as possible, adapting to whatever environment it’s running on. If the database isn’t “hands-off” for the DBAs to manage effortlessly, it’s going to make the entire microservices deployment a challenge.

6. Minimize the learning curve

The motto for any database in a microservices world is keep it simple. Otherwise, users will quickly become overwhelmed by the massive number of services its need to address. The database must come equipped with clear documentation, lots of instructional videos and a great support team to minimize the time spent learning how to use the new architecture. When there are questions or concerns, there should be an easily accessible link, document or help line that can give a clear and thorough explanation of what is wrong how to fix it.

7. Speak the same language

Polyglot persistence is now something users can use within new microservices applications. After a decade of fighting, now relational and nonrelational models are friends. Teams can use both ways of managing data, albeit on different services. Minimizing the languages databases need to speak reduces complexity by making it easier to understand what is going on as developers and operations teams are shifting work between services.

8. Scale up and out easily

Instant failover and high availability are the new standards for microservices. The beauty of microservices is that one service can go down and the others will still keep going. Taking it one step further, users should be able to create copies of each service and have it available if a node goes down, keeping every function of the application on at all times. As such, the database must offer the same. A distributed database enables rapid scalability making new nodes on demand. Real-time replication gives users multiple copies of their database for an always-on approach.

9. Extract, transform and load (also known as ETL)

In a microservices architecture, separation of services is the standard. Everything needs to be independent from one another, but should still share data. ETL is an easy way to have the database infrastructure take care of that. An ETL acts as a runner, signaling the next service to start executing. It also enables the application to be robust, distributed and fault tolerant.

10. Gather the data

The end product of a microservices system is a jigsaw puzzle of various sets of data being generated by its own, independent service that needs to be put together in real time. Data management strategies must incorporate technology and tools that put the data together to produce the metrics decision-makers need on an ongoing basis. At the end of the day, the head of an organization and the manager of the application must be able see all the data in one place. This data aggregation should be able to answer questions such as:

• How are the analytics as a whole for the day? The month? Even the hour?
• Is the return on investment positive for the current quarter?
• Is there justification for a features upgrade over the next 6 months?

The right database with the right characteristics can help to take an organization’s microservices efforts to the next level. Before setting out on your next microservices adventure, be sure to consider each of these 10 traits to take advantage of the latest technology trend and keep the best of features in the hands of your users at all times.