Perhaps the busiest person in enterprise IT: the database administrator. DBAs are tasked with keeping legacy databases tuned and running smoothly. This is Job 1, because these systems process all the vast majority of business transactions today. DBAs also have to find time to support modern microservices architectures. Often, these modern applications are built around the edges of legacy systems. Both types of systems, legacy and modern, compete for the DBA’s time.
Compounding things, managing large legacy databases and microservices’ backing stores is a very different operational model. Legacy databases require large, dedicated staff, while the microservices backing stores are numerous and cannot be operated with the same degree of individual attention. What a quandary!
MySQL 2.3 for Pivotal Platform aims to ease the pain associated with microservices database management. Let’s take a spin through the latest round of enterprise-grade features.
Secure Communications via Transport Layer Security
Security is top of mind. Every enterprise is concerned with bad actors gaining access to its network and collecting sensitive data. One attack vector used by hackers is by watching unencrypted network traffic. This vulnerability has the potential to reveal highly sensitive customer data.
To prevent this kind of breach, MySQL for Pivotal Platform supports IPSec and has for some time. We’re excited to give customers the option to use TLS, and we’re pleased to offer TLS in MySQL v2.3 as a way of ensuring that 100% of your communications, including data in motion, is secure. This will help you protect customer data in transit. TLS can also help you comply with regulatory certifications and standards.
Getting Started with TLS in MySQL
With MySQL v2.3, operators can quickly set up TLS, without downtime. Operators don’t have to deal with the complexity of certificate generation. In the event of a security exposure, operators can manually rotate a service’s certificates. For developers, it’s easy to opt into using TLS with new and existing apps. The simplicity of setup and use of TLS allows both operators and developers to focus on business value. Data encryption “just works”!
Now, let’s take a look at how to get started with TLS.
For Operators: Initial Setup & Provisioning TLS
Figure 1. TLS Configuration Screen for Operators
First, the operator needs to prepare the Pivotal Platform foundation for TLS. This has to be done only once per foundation. To reap the benefits of TLS, you’ll need to either provide a Certificate Authority (CA) to Credhub or have Credhub generate one for you. This way, each platform service can be deployed with a server certificate. The CA is distributed across the platform. When the MySQL service publishes an encryption certificate, a client can validate that the certificate is generated by somebody it trusts before communicating across a secure channel.
Generating the Certificate Authority
Operators can use Credhub to generate a CA, or they can opt to bring their own CA, provided by their enterprise public key infrastructure (PKI). Every instance of a multi-tenant service is distributed in the form of a BOSH deployment. This workflow related to preparing for TLS is shown in the video below.
For Developers: Using TLS
Configuring a MySQL service instance to accept TLS is the first step. Once the certificate has been provisioned, developers can accomplish this via a few simple steps.
Developers also need to modify their apps to use TLS. Depending on service client, applications must be changed in one of two ways:
Java and Spring apps will automatically detect if TLS is specified in VCAP_SERVICES. In order to activate TLS for Java and Spring apps, it is necessary to stop and re-bind the application.
Other applications need to be modified to discover the CA public key in VCAP_SERVICES. Developers will need to specify that CA component when initiating the connection to the data service. If encryption has been enabled after the service instance has been created, it will be necessary to re-bind the application, following the same process as above.
These steps related to using TLS are shown in the video below.
Use Leader-Follower to Increase the Availability of Your Database
To optimize for performance, adopt asynchronous updates. Here, the leader sends back an acknowledgment to the client as soon as it receives an update, i.e. before replicating it to the follower. This non-blocking interaction favors performance but takes on the added risk related to writes that the leader has acknowledged just before it crashes (prior to replication). These updates are now lost forever, which can be problematic because of their ‘silent’ nature. There is no easy way to identify all the updates that were missed because of a failure.
For many use cases, data consistency is the priority. Consider the case where the database is the system of record. You need a recovery point objective of zero data loss. In these cases, MySQL v2.3 can be configured for synchronous replication between the leader and follower. The acknowledgment is not sent to the client until both the leader and the follower are updated.
Typically, the leader and follower will be in different availability zones. The performance of synchronous replication is subject to the high-speed interconnections that are used across availability zones. The performance of synchronous replication is not as prohibitive as it would be over a wide-area-network.
Scaling the Administrators
The move towards distributed applications brings a commensurate move towards distribution databases and geographies. While microservices solve a lot of problems related to development velocity and release cycles, they do add an operational burden related to managing a large and growing count of database instances. MySQL for Pivotal Platform should be part of your cloud-native data strategy.
We’re on a journey to make MySQL for Pivotal Platform scalable in every way, including the administration of a large number of instances. The addition of TLS to MySQL v2.3 makes the service “secure by default.” Synchronous replication between leader and follower reduces the risk of data loss from leader failure. With these new features, ops teams have two fewer problems to worry about and can focus more time on delivering business value.
About the AuthorMore Content by Jagdish Mirani