“Google’s Cloud Build is just CI/CD for everything *but* the database”
No matter how good Cloud Build might look on paper, no product is flawless and Google’s new CI/CD service is no exception. We talked to Robert Reeves, Chief Technology Officer of Datical about the project’s flaws, the importance of giving the database team the attention it deserves and more.
Cloud Build, announced at this year’s Google Cloud Next conference, is Google’s new continuous integration/continuous delivery (CI/CD) service. One of its biggest benefits is that it’s integrated with popular developer tools and lets you build serverless applications:
- Native Docker support
- 120 free build-minutes per day and up to 10 concurrent builds included
- Powerful insights into build results along with build errors and warnings for easy debugging
- Automatically perform package vulnerability scanning for Ubuntu, Debian, and Alpine
- Build locally or in the cloud
You can give it a go for free here.
Still, no matter how good it might look on paper, no product is flawless and Cloud Build is no exception. We talked to Robert Reeves, Chief Technology Officer of Datical about the project’s flaws, the importance of giving the database team the attention it deserves and more.
JAXenter: Cloud Build is Google’s new CI/CD framework which promises to help developers build software quickly across all languages and define custom workflows for building, testing and deploying across multiple environments. It looks good on paper but what is it missing?
Robert Reeves: All applications are data-driven. Every website is data-driven. We see over 80 percent of application releases require some sort of database schema change. So, when you offer a CI/CD solution that doesn’t help for 80 percent of your releases, you are only solving 20 percent of the problem.
There is nothing in this solution that helps with database schema changes. Thus, Google is asking their users to manually change the database while automating the compiled apps. This will just create more of a strain on already overburdened database administrators (DBAs).
JAXenter: Is the database the most important part of the application stack?
Robert Reeves: The database is the most important part of the application stack because regardless of the speed or scale at which dev teams are able to build, test and deploy software if the database team cannot keep pace, the entire release comes to grinding halt.
Google is asking their users to manually change the database while automating the compiled apps. This will just create more of a strain on already overburdened database administrators (DBAs).
At the end of the day, the “system of engagement” (the app) is going to change repeatedly based on the platform (from client-server, to web, to mobile, to AR/VR, to who knows?), but the “system of record” is going to remain. For example, Sabre uses an IMS database because that was what they used when they first built it. However, we can now buy airline tickets on our smartphones. If that mobile application gateway goes down, people can still buy tickets online or go to the airport. However, if the database goes down, then every app is down.
JAXenter: What is the downside of not giving the database team the attention it deserves?
Robert Reeves: The software release cycle can only go as fast as its slowest part. By neglecting the database team, Google and other CI/CD providers will not be able to truly deliver on the promises they’re making around faster software delivery. DevOps teaches us to identify the areas in our release process that take the most time or have the most failure. In every single company I have seen, that has been the database.
No matter what you do to speed up and ease the process of releasing the compiled bits, you will never be faster than the database. In fact, you can cause serious problems for your data team by increasing their workload without automation. They will simply spend less time reviewing each change, which leads to more errors. Also, queuing theory tells us that if you increase a system load by 10 percent, you double the wait time. Thus, if you increase the load on your DBAs by 10 percent, you will double the amount of time it takes to complete a change.
JAXenter: What are the benefits of Google Cloud Build?
Robert Reeves: Google Cloud Build is certainly an improvement upon maintaining your own CI/CD solution. But, it’s just CI/CD for everything but the database.
JAXenter: What do you think about Google Cloud Build?
Robert Reeves: Love it. 120 hours of free build time? I’m in. I’m very happy to see more choices for development teams. That keeps the other cloud providers honest and puts the pressure on them to deliver compelling offerings for their users.