Rocky Van Schuylenburch's presentation during Seminar Modernizing Your Development Using Microservices, Container & Kubernetes

1. October 2019
Containerizing
Your Workloads
with Google Cloud
Rocky van Schuylenburch
Solutions Architect, Cloud Ace

2. 01Who we are?
Introduction to Cloud Ace

3. Cloud Ace, Inc.
Established in
November 1st, 2016
Tokyo, Japan
by Ayatoshi Yoshidumi

4. Company history
2005
Establishment
of Yoshidumi
Information,
Inc.
2009
Google
Enterprise
Partner,
Authorized
SMB Reseller
for Google
Apps
2017, Oct.
GCP Training
Partner
2017, March
Partner Award for
Google Cloud
Platform™
Customer Success;
Google Cloud
Platform
Premier Partner
2011
Google App
Engine
Premier
Account
(1st in Japan)
2014
“Cloud Ace”
service
launch,
First GCP
resale
business in
Japan
2016
Cloud Ace splits
up from
Yoshidumi
Information, Inc.
Cloud Ace, Inc.
is established
2018, Feb.
Google Cloud Partner
Infrastructure
Application
Development
Specialization
(1st in Japan)

5. World leading 8 specializations

6. World leading 200 certifications

7. Global
expansion
Bangkok (Thailand)
Taipei (Taiwan)
Tokyo, Osaka, Nagoya & Fukuoka
(Japan)
Ho chi minh (Vietnam)
Jakarta (Indonesia)
Singapore

8. Why?
The business benefits that
container technology provides and
understanding the key reasons
why would one use it.
How?
Simple steps you can take to
move your applications to a
containerized architecture.
What?
A simple understanding of what
container technology really is,
cutting through the jargon and
buzzwords.
Goals for the session

9. 02What is the big idea?
Develop common understanding

10. Enterprise IT
is complex
Businesses
demand agility

11. New requirement to launch / scale
mobile component of an existing
legacy app
IT Teams build mobile backend
based on existing legacy
architecture
Difficult to migrate / break apart existing
app due to hard dependencies in
on-prem environment
At launch, unpredictable traffic
spikes, causing downtime
Team decides to switch environments
and replatform their app, forcing a
full rewrite due to inflexibility of
legacy systems
The mobile component needs to be
developed, configured, secured, and
scaled differently in each environment it’s
deployed
Legacy software development
practices hurt productivity...

12. What could have happened:
Standardized
on containers
Redundant
deployment to
multiple nodes
Avoided outage completely,
keeping customers happy
What did happen:
Power outage Cancelled flights
causing outrage
Lost billions
of dollars
Business critical applications
built on legacy systems makes
agility nearly impossible

13. The true cost goes beyond lost time
Lost:
Opportunity for
innovation
Lost:
Team
morale
Result:
Technical
debt
Result:
Increased
complexity

14. Applications aren’t
tied to underlying
infrastructure or vendors...
...addressing
issues of tight
coupling
Container based methods offer
a flexible approach to infrastructure

15. Some associated buzzwords
● Lightweight
● Portable/Standard
● Productivity
● Secure
What are containers?

16. Image
A method of packaging an executable application and its
dependencies (runtime, system tools, system libraries, configuration)
Runtime
Running the package as a set of resource-isolated processes
Containers are about two capabilities

17. Use Linux kernel features to support process isolation
● Put all dependencies within the image
● Run with specific CPU and memory limits
● Isolate from other processes
● Give limited access to the file system
libs
app
kernel
libs
app
libs
app
libs
app
Container virtualization

18. Comparison with VMs and shared hosts
app
libs
kernel
libs
app app
kernel
app
libs
libs
kernel
kernel
libs
app
kernel
libs
app
libs
app
libs
app
kernel
libs
app
app app
app
Shared machines Virtual machines Containers
No isolation
Common libs
Highly coupled apps
and OS
Isolation
No common libs
Expensive and inefficient
Hard to manage
Isolation
No common libs
Less overhead
Less dependency
on host OS

19. Lightweight
Containers contain only what is
necessary, so the same host can run
multiple containers.
Portable
Containers package all the
dependencies into the image;
therefore they do not rely on host to
provide anything other than basic
compute resources.
Fast
Containers (which run as processes)
take less time to start up given that
the host is already running and has
the container image downloaded.
So let’s revisit the buzzwords

20. 03
What does it mean
for my business?
Advantages of containerization

21. Containers are the first step toward abstracting infrastructure
● Image includes all dependencies and can therefore run on wide variety of hosts:
‐ IaaS (VMs), PaaS (Kubernetes Engine), App Engine, and serverless
● Easy to scale up and down (process vs. VM)
● Quicker release cycles
Enabling technology

22. Compute
Engine
Kubernetes
Engine
App
Engine
gcloud beta compute instances create-with-container hello-world
--container-image=hello-world
kubectl run hello-world --image=hello-world
gcloud app deploy --image-url=hello-world
One image, many runtimes

23. IaaS SaaSPaaS
Servers
VM instances
Clusters
Cluster management
Serverless, autoscaling
Google Cloud Platform products and services
Compute
Engine
Kubernetes
Engine
App Engine Cloud
Functions
App Engine
flexible environment
Choices of runtimes

24. A fundamentally different way of managing applications
requires different tooling and abstractions
● Deployment
● Management, monitoring
● Isolation
● Updates
● Discovery
● Scaling, replication, sets

25. Once specific containers are no longer bound to specific machines/VMs,
host-centric infrastructure no longer works
● Scheduling: Decide where my containers should run
● Lifecycle and health: Keep my containers running despite failures
● Scaling: Make sets of containers bigger or smaller
● Naming and discovery: Find where my containers are now
● Load balancing: Distribute traffic across a set of containers
● Storage volumes: Provide data to containers
● Logging and monitoring: Track what’s happening with my containers
● Debugging and introspection: Enter or attach to containers
● Identity and authorization: Control who can do things to my containers
GKE provides container-centric infrastructure

26. Think of Kubernetes as the OS for your compute fleet
● Scheduling workload
● Finding the right host to fit your workload
● Monitoring health of the workload
● Scaling it up and down as needed
● Moving it around as needed
It provides features similar to an OS for a host:
In simple terms...

27. Kubernetes Engine overview diagram
Kubernetes
Engine
architecture
In Kubernetes Engine, a cluster
consists of at least one control
plane (master node) and
multiple worker machines
called nodes. The Kubernetes
control plane has processes
including the Kubernetes API
server, scheduler, and core
resource controllers.

28. 04How to get there?
Roadmap and pointers

29. Inventory and
classify your
applications
First:

30. Group 1
First movers
Stateless applications
● Web front ends
● (Micro)services
● APIs

31. Group 2
Second movers
Temporary state
● Master/Slave components
● Caching (Redis, memcache, etc.)
● Service discovery (ZooKeeper, Consul)

32. Group 3
Lowest priority
Stateful applications
● Databases
● File servers
● Storage

33. Containerize parts
of the application
Second:

34. Positives
● Prove the concept
● Get comfortable with the technology
Drawbacks
● Don’t get the full benefit
Clients
Cloud Load
Balancing
App data
Cloud SQL
App
Compute Engine
Monolithic applications

35. Cloud Load
Balancing
App data
Cloud SQL
App front-end
Compute Engine
App back-end
Compute Engine
Clients
Positives
● Scale tiers individually
● Closer to microservices architecture
Drawbacks
● Still don’t get the full benefits
Three tier applications

36. Cloud Load
Balancing
App data
Cloud SQL
App front-end
Compute Engine
App legacy
back-end
Compute Engine
Service A
Compute Engine
Clients
Positives
● Toes in the water of microservices
● Does not affect existing monolith
Drawbacks
● Challenges with the monolith persist
Transitional microservices architecture

37. Cloud Load
Balancing
App data
Cloud SQL
App front-end
Compute Engine
App legacy
back-end
Compute Engine
API Gateway
Compute Engine
Service A
Compute Engine
Clients
Positives
● Hide details of the endpoints from
clients and frontends
● Easily change service endpoints
behind the SCE
Drawbacks
● More work to build gateway
Microservices with API Gateway

38. Cloud Load
Balancing
App data
Cloud SQL
App front-end
Compute Engine
App legacy
back-end
Compute Engine
API Gateway
Compute Engine
Service A
Compute Engine
Service B
Compute Engine
Service N
Compute Engine
Clients
Positives
● Scale services individually
● Services follow independent
lifecycle
Drawbacks
● Requires organizational maturity
True microservices architecture

39. Recognize
this pattern?

40. Case Study
Third:

41. Cloud Ace success
story with GKE:
Project “MangaWith”

42. Project “MangaWith”
GameWith Co., Ltd. operates the largest game application
information and capture site "GameWith" in Japan. Listed on
TSE Mothers in 2017. It is now attracting attention as one of
the fastest growing companies.
In December 2018, GameWith released "MangaWith", a web
manga service for smartphones. Together with major
publishers, it offers over 150,000 electronic comics. GCP
(Google Cloud Platform) supports this "MangaWith".
Google Cloud official
case "GKE adopted
with a view to
containerization and
multi-cloud" build
"MangaWith" in a short
time of about 6 months
until release is here
Used Google Cloud Platform service: Google Kubernetes Engine,
Google Cloud Load Balancing, Container Registry, Stackdriver
Logging, Google BigQuery, Cloud SQL, Google Cloud Storage,
Cloud Memorystore

44. Thank you.