In part 1 of this blog series, I explained microservices architecture. Now, let’s look at microservices applications in more detail. Although microservices architecture does not have to be cloud-based, it is common for applications delivered in microservices to be deployed in the cloud using infrastructure-as-a-service (IaaS).
IaaS model
IaaS is a model that essentially leverages commodity hardware and virtual machine technology to create an infrastructure that is owned and maintained by a third party. IaaS looks and feels like an on-premises or collocated data center, with the exception that the “data center” is in the cloud and billing is based on consumption and usage.
With IaaS, the use of containers is fairly common, and while they’re not required for microservices-based applications, they’re certainly handy. Containers are small packages that include the software or service and its dependencies within a distinct unit (similar to a virtual machine). Containers isolate applications and services from each other as they run on top of a shared operating system with the advantage of a significantly smaller footprint than virtual machines.
When applied to a microservices deployment, using containers results in fewer interdependencies, a smaller footprint for portability, and application scalability – all while maintaining control over the full application stack. Other advantages of this approach are that it helps avoid cloud vendor lock-in (since everything is portable), and lower-cost, open-source technology can be used, such as MySQL, PostgreSQL and Kubernetes.
Despite these advantages there are important considerations for DBAs, DevOps engineers and others who maintain and administer microservices applications. These include database performance management, cost control and visibility.
Performance impacts
Database performance remains a critical aspect for any application, and running in a microservices architecture doesn’t alter that. This is particularly true for those applications and databases that handle a high volume of transaction processing. The root cause of most performance issues is generally unexpected volumes of users, compute, or data. The application or microservice may have high transaction volumes, which can create performance bottlenecks. Poorly-written SQL statements and long-running queries do not magically disappear within microservices. While you can always solve the problem with more compute cycles, there is a significant cost associated, whereas tuning the queries would improve performance without incurring more cost.
Cost considerations
Cloud costs can be convoluted and difficult to estimate, resulting in budget overruns and unpleasant monthly bills. When dealing with microservices in the cloud, DevOps and DBA teams must now consider the cost implications for many technology and architectural decisions that they didn’t previously. For example, if each microservice is running on its own database, it’s highly likely that it will also have development, test, staging, and production environments. With a commercial database platform, you could have license costs for each microservice multiplied by four.
Open-source databases in containers may not incur direct licensing costs, and this is why development teams often choose community open source projects when building microservices applications. However, even if you avoid direct licensing costs, you’ll still have the other costs associated with compute, storage and data consumption.
Inherent risks
Estate sprawl is another risk inherent with running microservices on IaaS, especially without good visibility. This presents a security risk due to managing configurations and patching levels across the estate, and it also becomes a cost that has to be managed.
DevOps teams that support microservices applications in IaaS need visibility and tooling for this complex landscape. Visibility into database performance helps them optimize performance, especially if they can tune queries without affecting cost. Visibility into the estate prevents sprawl, optimizes consumption and reduces cost. Third, visibility into each microservice and container allows you to more effectively scale, cluster and maximize performance when utilizing Kubernetes for container orchestration.
Conclusion
For a single solution to gain visibility into database performance, container performance and cost for microservices applications, consider Foglight® by Quest®. Foglight is an enterprise performance monitoring and optimization solution for the hybrid enterprise. It features deep diagnostics and cost optimization for modern development and microservices architectures. Foglight is cross platform and can support a homogeneous or heterogeneous microservices estate.
