Ernesto Garbarino - Beginning Kubernetes on the Google Cloud Platform: A Guide to Automating Application Deployment, Scaling, and Management

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/978-1-4842-5490-5 . For more detailed information, please visit http://www.apress.com/source-code .

About the Author

Ernesto Garbarino

is a consultant in the Digital, Cloud, and DevOps domains. His 20-year experience ranges from working with early startups and entrepreneurial organizations during the dot-com era, to senior consultancy work in blue chip industries including telecoms, logistics, and banking. He holds an MSc in Software Engineering with Distinction from the University of Oxford. He lives in Egham, United Kingdom with his two loves; his lovely wife, Adriana, and his sweet black and tan dachshund dog, Daisy.

About the Technical Reviewer

Jing Dong

is an entrepreneur and technologist with a wealth of experience in software engineering, container orchestration, and cloud native magics. He started programming in 1994 when he was nine years old. His passion for distributed systems led him into reaching data and scalability challenges in both technical and cultural aspects. He architected and engineered many large-scale applications and data platforms for F1 motorsport, disaster prediction, online media, and financial services. He holds an MSc in Computing in Distributed Systems from Imperial College London. Electronic components and flying robots occupy the rest of his free time. He lives in the United Kingdom with his beloved wife and son.

In 2016, my end customer was a global logistics company in the process of upgrading a 15-year-old monolithic clearance system based on an application server (WebLogic), a relational SQL database (Oracle), and messaging queues (TIBCO). Every component in each tier was a bottleneck in its own right. The four-node WebLogic cluster could not cope with the load, the slowest SQL queries would take several seconds to process, and publishing a message to a TIBCO EMS queue was akin to throwing a feather into a 100 meter well. This was a mission critical system that made possible the transit of goods through various clearance centers across the European Union. A crash (or significant slowdown) of this system would have implied empty shelves in several countries and offices, waiting for overnight documents, grinding to a halt.

I was appointed with the task of leading a team in charge of rearchitecting the system. The team consisted of highly qualified subject matter experts in each technology tier. We had expertise in most of the tools that would help create a modern, highly scalable, and highly available application: Cassandra for NoSQL databases, Kafka for messaging, Hazelcast for caching, and so on. But what about the Java monolith? We had broken down the application logic into suitable bounded contexts and had a solid microservices architecture blueprint but could not get a containerlet alone container orchestrationexpert to give us a hand with the design.

I was reluctant to adding more activities to my already busy agenda, but I was so desperate to see the project through that I said to myself: what the heck, Ill take care of it myself. The first week, after struggling to wrap my head around the literature on the topic, I thought I had made a big mistake and that I should talk myself out of this area of expertise. There were an overwhelming number of self-proclaimed container orchestrators in the marketplace: Docker Swarm , Apache Mesos , Pivotal Cloud Foundry the customers favoriteand of course, Kubernetes . Each had radically different concepts, tooling, and workflows for the management of containers. For example, in Cloud Foundry, pure Docker containers were a second-class citizen; developers were supposed to push code directly into the platform and let it be matched with its runtime in the background via a mechanism known as build packs. I was dubious about Pivotal Cloud Foundrys approach which felt just like WebLogic all over again where a single missing dependency on the server side would result in a failed deployment.

I tried to deal with the problem with an architects glasses, by understanding concepts, looking at diagrams, and working out how the components worked together, but I simply did not get it. When it came to hard questions such as How does a zero-downtime migration