How Google Cloud Build… Builds Cloud Apps

By:  Adrian Bridgwater

We’ve said it before. In the world of cloud, the application is always on and this has created a world of continuous computing where nobody ever turns the Internet off. This always on, always connected, always updating element of cloud computing has given rise to what we normally refer to as Continuous Integration & Continuous Delivery (CI/CD).

We know that Facebook ‘deploys’ a new software build several times a day. But usually, we the users don’t notice because we access this cloud-based software through a web browser or connected mobile application – so all the engineering happens at the back end. This is considered to be rapid release at massive scale and therefore Continuous with a CAPS C.

Embrace, with restraint

Technology vendors are now working to put continuous CI/CD software tools out into the market. Customers see these tools and would generally like to embrace them (who wouldn’t want to be more always on?), but bringing them to bear and shouldering the engineering cost and complexity of operating and maintaining a secure and reliable CI/CD infrastructure is high.

The trouble is, engineering towards Continuous Nirvana is nice, but software department resources are very often directed towards simply writing functional software for immediate use cases where it is needed.

Google has now set out to try and tackle this predicament. Obviously the firm operates a great many ‘instances’ of enterprise cloud for enterprise customers. It gets to see what data requirements these customers experience, what processing requirements they need and what kinds of pain barriers they go through when trying to build, test and ultimately deploy software into the Google Cloud.

Google Cloud Build

Enter the almost innocuously named Google Cloud Build.

This is a product, from Google, for building software, in the cloud model, hence the name. Google would call Cloud Build a ‘platform’, but we might reasonably argue that the Google Cloud service is the platform upon which we put the apps. This is more of a fully managed cloud application development environment with an associated set of set of build and test management tools that also encompasses automation and workflow controls along with privacy and vulnerability analysis intelligence.

That’s way too long. It’s basically a set of software designed to help create always on cloud apps in the continuous world of cloud.

Google vice president of engineering Melody Meckfessel has said continuous computing means that software teams need to deliver more business value faster than ever. But this propensity for speed and change can also come at a cost i.e. new vulnerabilities are discovered every day and seemingly innocuous updates can cause applications to break.

“The best time to catch and fix a problem is as early and automatically as possible. In software, a similar culture of continuous improvement is essential, along with new tools to automate best practices, like Continuous Integration & Continuous Delivery (CI/CD). In creating Cloud Build we worked with and listened to software developers from every walk of life, on teams of every size. We also spent time understanding what helped our own internal engineering teams be productive,” stated Meckfessel, in a Google blog post.

Meckfessel claims that this ‘listening’ from Google allowed the company to identify three stand out factors in the world of cloud software application development.

Scalability, flexibility & security

Scalability is key, she states i.e. no build is ever too quick and no test suite was ever accused of running too fast. As a project grows over time and new developers join the team, the CI/CD system must keep up. Google’s answer to this is flexible pricing with a range of CPU sizes available for customers who require different amounts of cloud application processing power.

Pointing to the flexibility factor, Meckfessel has said that software development is an increasingly complex web of ever-changing frameworks, dependencies, services, languages and tools.

“Applications are deployed across multiple clouds, on-premise resources and mobile app stores. To support development needs, Cloud Build works with major source repositories like GitHub, GitLab, Cloud Source Repositories and BitBucket. It also features built-in support for Docker, Maven, Gradle, Bazel, Go and npm. An ecosystem of add-ons and the ability to bring your own tasks and toolchains as containers makes integrating into your existing developer workflow easy,” said Meckfessel.

Finally Meckfessel highlights security. Saying that security isn’t just for runtimes (i.e. when an application is actually executing), she says that it’s a full lifecycle problem that extends into every tool and pipeline in use. To address this, Cloud Build uses security and policy controls — and Cloud Build runs every build on its own Virtual Machine (VM), which reduces the risk of information leaking between builds or build errors caused by inconsistent build environments.

Of course this is Google, so not everybody will be sold on this monolithic company’s mantra. Robert Reeves is co-founder and CTO Datical, a provider of database release automation software that supports accelerating application release cycles.

Another day, another CI/CD tool that forgets the most important part of the application stack: the database,” rebuffs Reeves. “Regardless of the speed or scale that dev teams are able to build, test and deploy software, if the database team cannot keep pace, the entire release comes to grinding halt. While Google Cloud Build is certainly an improvement upon maintaining your own CI/CD solution, the software release cycle can only go as fast as its slowest part. If Google and other CI/CD providers want to be able to truly deliver on the promises they’re making, they need to take the database into account.”

Asked to further substantiate his criticism, Reeves reminds us that all applications are data driven and every website is data driven. He further notes that over 80% of application releases require some sort of database schema change.

“So, when you offer a CI/CD solution that doesn’t help for 80% of your releases, you are only solving 20% of the problem. There is nothing in this solution that helps with database schema changes. Thus, [i.e. Google] is asking its 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),” specified Datical’s Reeves.

In summation then, Google probably hasn’t completely forgotten database engineering elements in terms of how it takes Cloud Build to market, but… that being said… the emphasis at launch is certainly one more focused on upper tier developer needs.

In fairness to Google (and most of us don’t spend a lot of time defending the company), we don’t have enough developers globally, we don’t have enough cloud developers and we don’t have enough cloud-first developers who are born and bred on building in this new model of service-based computing where we draw power from the datacenter backend.

So if Google can save some of the time eliminating manual processes throughout the development and deployment cycles with automated build, test, artefact management and deployment tools – then developers can focus on writing cloud code… and that’s mostly a good thing.