PRIYANKA VERGADIA: Well, it turns out
that switching to microservices is not
that easy without a plan and a process,
so you need to keep watching to learn more about the migration
process.
[MUSIC PLAYING]
CARTER MORGAN: The microservices-based
architecture is beneficial due to its loosely coupled
components that can be independently
tested and deployed.
In theory, the smaller and simpler a component is,
the easier it is to maintain and deploy.
PRIYANKA VERGADIA: And each independent service
can be implemented in different languages and frameworks
so you can use the right tool for the particular job you're
trying to do.
CARTER MORGAN: Each component can
be managed by a different team, reducing
dependencies between teams.
This clear boundary between services
allows a team to more easily design for failure,
and it becomes easier determine what
to do if a service is down.
PRIYANKA VERGADIA: But does this mean
microservices are as perfect as a homemade souffle?
Well, no.
You see, with monolithic platforms,
every logical component can speak to every other component
pretty much by default because they're
all part of the same whole.
But with microservices, even though
each individual component is simpler and easier to manage,
how those services work together to communicate and to behave
as a system is more complicated and possibly slower due
to the added network latency.
CARTER MORGAN: Still, many, including Google,
has been doing this for many years.
Many believe that microservices are a big win
overall for most organizations.
But if you don't design your microservices correctly,
you may end up with a distributed monolith.
And that's even worse than the monolith
you had in the first place.
It can take months to actually migrate.
PRIYANKA VERGADIA: So we definitely know
it's not going to be simple.
But to help simplify that process--
and because with any recipe, it's
important to know what the end result is going to look like--
let's map the path from a monolithic, on-premise
application to an application that's
fully hosted on Google Cloud Platform
and built with microservices.
CARTER MORGAN: If you have already
migrated your monolithic application
as is into the cloud, then the same steps we discuss here
can be applied to create microservices architecture.
For most e-commerce platforms, the starting point
is a monolithic application on premises.
Your platform will probably have load balancers to handle
incoming requests from the web.
These requests will be routed to your application servers.
These application servers are responsible for processing
the requests by utilizing components like cache,
database, search, et cetera.
Additionally, your app servers may send requests
to other back-end systems.
Obviously, this can't be fully representative
of your current system, but it should
serve as an example that's similar in theory
to yours so you can migrate it towards our target
architecture.
PRIYANKA VERGADIA: Now let's talk
about the end state, what we are trying to achieve.
We definitely want to achieve the same functionality,
as Carter mentioned, in the monolith,
except now, instead of running a monolith,
we would break that up into individual microservices
running in portable, deployable units of code called
containers, using Google Kubernetes
Engine, a platform that handles scaling,
hosting, and deploying containers.
In this architecture, each microservice
runs in its own containers and makes
call to the back-end system through a secure network
connection.
We are still routing internet traffic through a load
balancer, but now the traffic is routed
into separate microservices.
This lets us update version of individual microservices
while only minimally affecting the other services.
And in our target architecture, the microservices
may interact with a number of other GCP products.
Cloud Storage, Cloud SQL, and Cloud Pub/Sub
are common GCP products for e-commerce applications.
So Carter, how do we make this happen?
CARTER MORGAN: One of the most important decisions
you must make early during this migration
is how to handle communication between the new microservices
hosted on GKE and your legacy system on premises.
Since we're migrating in stages, there
will be large periods of time where
components of your platform will be living in both GKE
and on premises.
Now, there are two main solutions,
and they can co-exist--
API-based communication or communication
based on a private network connection.
PRIYANKA VERGADIA: In the API-based solution,
you use an API management solution, such as Apigee,
as a proxy between the two environments.
This gives you a precise control over what portions
of your legacy system you expose and how you expose them.
It also lets you seamlessly refactor
the implementation of an API--
that is, moving from a legacy service to a microservice--
without impacting the consumers of the API.
CARTER MORGAN: In a solution based on private connectivity,
you connect your GCP and on-premise environments
using a private network connection.
The microservices communicate with your legacy system
over this connection.
You can set up IPsec-based VPN tunnels with Cloud VPN.
For larger bandwidth, high availability,
and low latency needs, Cloud Interconnect
is a better option.
PRIYANKA VERGADIA: Now let's compare and contrast
the two communication options.
Compared to private connectivity,
an API-based solution is implemented by the application
teams and requires a greater integration with the legacy
application from the get go, so it is harder to set up
but provides more management options in the long run.
On the other hand, a solution based
on Cloud VPN or Cloud Interconnect
will be implemented by a networking team
and initially requires less integration with the legacy
application, but it does not provide any added
value in the long term.
CARTER MORGAN: Now that we know more about these communication
options, we can combine the two approaches
and use them to our benefit.
For example, we can use Apigee only
for the public APIs in front of the microservice and legacy
systems but not between them, and Cloud VPN or cloud
internet for the communication between the microservice
and legacy systems.
This option combines the benefits of the two approaches
but is more complex to manage.
PRIYANKA VERGADIA: One of the other choices
we have to make when migrating is
which GCP technologies to use.
For example, do you want to use Cloud Bigtable to store data,
or do you want to keep using some
of your current technologies because they're still
relevant to you or because the cost of moving them
is too high?
You should think about these choices
as a part of the migration process.
CARTER MORGAN: Here's the point.
This is a complex process that won't happen overnight.
So any planning you do beforehand,
like how will my services communicate,
how will I manage data, what should I migrate first--
any of this goes to help make sure the process goes smoothly.
For more information about alternative migration
approaches, check out the article
written by Marco [INAUDIBLE].
PRIYANKA VERGADIA: Well, there you have it.
If you are in the process of migrating a monolith
to microservices, then you got a small taste of the process
here.
Stay tuned for the next episode, where
we will be discussing the migration in stages.
That's all for today on "Get Cooking in Cloud."
If you liked this video and would
like to see more such content, don't
forget to like and subscribe.
[MUSIC PLAYING]