Why A Microservice Architecture Needs DBaaS [feedly]

----
Why A Microservice Architecture Needs DBaaS
// Build AWS-compatible Private Clouds with CumuLogic

The microservices architectural pattern is quickly becoming synonymous with what people consider to be "cloud native" systems. As companies are shifting to a model of cloud-first for new applications, and even re-thinking their approach for some of their core systems, the microservices approach is gaining in popularity.

While most discussion of microservices is focused on the application architecture, there is less being discussed about the impact of this architectural approach on the data persistence layer, application DBA's and how DBaaS can be a helpful component to successfully building new applications as a set of microservices. In this post, we'll touch on some of the higher level concepts that the microservices approach implies, paying particular attention to the "data" impacts.

What's a Microservices Architecture?

In essence, the microservices pattern is one where a software system is comprised of a number of independently deployable services, each with a limited scope of responsibility. Typically, the scope of responsibility is considered to be some particular aspect of business capability that it can own end to end. In some cases, a microservice might rely on other lower-level services to deliver it's functionality, but this is less frequent than purely independent services.

The microservices architectural approach allows for each service to be developed by independent teams, scaled individually and managed as a product throughout it's lifecycle. A well implemented microservices architecture also ensures that the overall system is able to gracefully degrade it's functionality of one or more services are offline.

Monolithic vs Microservices Architecture

To achieve the goals of the approach, that independence and isolation needs to be provided all the way down to the data persistence layer. What good is a group of independent services if they all relied on the same database system? Having a single database for the services would leave the system with a single point of failure, and reduce the ability of each service development team to truly operate as an isolated unit.

Organizational Impacts

Conway's Law is a particularly relevant adage worth understanding if you're planning on adopting the microservices approach to any team-based development effort.

It says:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. (M. Conway, 1968)

What we have found in the technology industry is that not only is that statement typically true, but that tendency can be harnessed to help drive the actual architecture of a system being built. If you are structured into teams that represent the "three tier" architecture, that architecture is the likely result of every project you embark on. Conversely, if your development organization is structured as a group of independent units, each responsible for some aspect of the software's overall business processes, you'll get a system architecture that reflects that organizational structure.

This isn't to say that organizing your teams into functional units will actually result in a good example of a microservices architecture being developed (there are too many other variables like team skill, etc…), but without taking Conway's Law into account you'll struggle to achieve the goal. It also doesn't necessarily require that reporting lines reflect your architectural goal. It's quite possible to get the same organizational dynamics through a matrix management approach as well.

This type of organizational thinking is particularly new for the DBA community, who are used to being a centralized team within most companies. We posted previously about our thoughts on Reinventing the role of the DBA, and it's particularly relevant to the microservices discussion. DBA's need to be part of each service team. Perhaps the effort required from a DBA isn't "full time" for a single team, so DBA's could certainly be shared across multiple service teams. What's important is for each DBA to understand that they are helping to create an isolated system within each services, and they should resist the instinct to centralize all of the data from each team they work with into a single database.

How Database-as-a-Service Supports Microservice Development

At this point, you should understand that adopting microservices as an architectural approach for your system can imply a number of thing that impact the data persistence layer, and the teams charged with being the data custodians for your organization. Specifically:

1. Each microservice, if responsible for storing any data, should have it's own database.
2. Independent teams may select different database technologies, based on their own needs.
3. DBA's should focus on being data experts for the service teams, but resist the urge to centralize data into a single system.

The obvious outcome of these implications is that there will be an explosion in the number of distinct databases, potentially different database engines and an increased operational complexity. This is where Database-as-a-Service can help. A good DBaaS environment should address each of these implications directly, reducing the management and operational concerns significantly.

Self Service – Letting each service development team instantly get new database instances means that they don't have to wait for a central DBA team to spin up a new environment.

Multi-engine Support – Having more than one database flavor in the DBaaS service catalog allows the service development teams to pick what's right for them, without concern for burdensome organizational "standards".

Fully Automated Operations – DBAs need to focus on helping the service development teams understand how to best work with the data they are responsible for, and a DBaaS approach to database operations significantly reduces the time they need to spend on the traditional "infrastructure-centric" aspects of being a DBA.

See How CumuLogic's DBaaS Platform Can Help

CumuLogic's DBaaS Platform is specifically designed to let organizations operate their own DBaaS platform, running on any infrastructure (public cloud, private cloud, or even bare metal). If you'd like to learn more about how CumuLogic could help your organization build software to be much more "cloud native", please get in touch or request a sandbox environment to try the system for yourself.

----

Shared via my feedly reader

Sent from my iPhone