The database world’s evolution is fascinating. We were familiar with traditional monolithic databases, and, in the last decade, we’ve become familiar with cloud databases. The main differences between these two are where data is hosted and its implications. The need to move from monolithic databases to database clouds is derived from the need for speedy data storage and overall resource reduction. In other words, scalability. Today, we are witnessing cloud storage evolving towards something even more flexible than a database-as-single-entity. This is where a framework for microservices would come into play.
The Fundamentals
In traditional monolithic applications or databases, all components and functions are hosted in a single instance. All tables, queries, schemas, programming languages, operating systems, etc. — everything — is in the same instance. So, if something changes, everything must adapt to that change. As the database or data warehouse grows, its complexity and maintenance cost grows. This has worked well over decades as the pace of data generation and storage has been manageable for engineers.
By contrast, in a microservice database, every database component is broken apart into smaller parts. Each component is independent of the rest; they communicate among themselves and outside the containerized application by using network/virtual network or application programming interfaces (APIs). In this architecture, if the microservices database grows, it is easy to locate the growing part and focus on maintaining only that part, leaving the complexity of maintaining the rest aside.
Why a Framework for Microservices is Needed
Microservices’ “divide and conquer” approach is designed to handle the complexity of today’s business world. However, there are some drawbacks, such as the increased complexity of managing many individual parts and the challenge of continuous integration of new services and tracing back errors. To mitigate all those issues, adopting a framework is essential. A framework is a ready-made structure for software development. It is not a “cookie-cutter” solution, capable of adapting to any need.
Frameworks save time on planning, execution, and development. There are a good number of frameworks available in the market, some open source and others commercially distributed. Three major examples are:
1. Docker and Kubernetes
Docker is the ‘go-to’ microservices software platform nowadays. It is open-source and it allows any developer to deploy any kind of application in a serverless way — in self-contained packages or blocks called ‘containers.’ Kubernetes is an open-source platform designed to orchestrate containers.
Working together, both platforms allow any application to run on any operating system and in any programming language, in a highly scalable way. This provides flexibility and high efficiency in terms of resource usage.
2. Oracle Helidon Microservices Framework
This is a microservices platform developed by Oracle, based on a repository of Java libraries. There are several variants of Helidon, such as Helidon MP and Helidon SE. Both variants are Java based applications, designed for asynchronous programming and reactive streams for Helidon MP; Helidon SE is especially suited for fast prototyping and a small resource footprint.
3. Eclipse Vert.X Microservices Framework
This is another popular framework that runs on Java Virtual Machine, and it supports many programming languages. One of the interesting characteristics of Vert.X is that the developed app can handle high concurrency by using a small number of kernel threads. It also allows fast scale with minimal hardware.
When selecting from these three or other microservices frameworks, make sure that the development team and those who maintain the framework understand the development requirements: how to structure the microservices reflecting the business operation and structure (and not the opposite way); how microservices will be communicating (API, network, virtual networks, etc.); and last, but perhaps most important, is security. Make sure that the solution and the provider have solid security measures in place.
Final Thoughts
While adopting microservices architecture is an important modernization step towards a more flexible, adaptable structure, it is important to first understand the business process and the customer journey, especially in regard to the generated data trace and how each team will manage it. Also, this process requires multiple iterations before having a minimum viable product (MVP), and bear in mind that this iterative process will never end.
