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.