- [Instructor] Cloud native application
development patterns,
also called 12- or 15-factor applications
are a set of patterns that have arisen with cloud computing.
Before we get into the considerations that exist
for applications targeting Kubernetes,
let's give some of the general thoughts
around 12-factor and 15-factor applications.
Now, I believe all of the factors are important
from a system perspective.
I want to focus on the details
within the scope of this course.
If you want a more in-depth conversation
on cloud native applications,
check out my course here in the LinkedIn Learning Library
on 12- and 15-factor applications.
The concept of a single application
running in a single process
is critical to cloud native applications,
especially in languages like Java.
The application server was the process,
and our apps were hidden behind that,
often running many apps in that single app server process.
This makes operations difficult to say the least
and obfuscates what is really important
to the development teams.
Kubernetes can deviate from this
depending on your perspective, however.
The use of sidecars and multiple container pods
tends to deviate from the operator's perspective
though they are indeed single process applications.
Understanding this is beneficial to developers,
but outside the scope of this course.
So I encourage you to pause here
and take a look at the concepts of sidecars
as well as multi-container pods in Kubernetes.
(upbeat music)
The ideas of prod and non-prod parity,
and strong development processes like CICD
are critical with cloud native applications.
Fortunately, with setups leveraging Kubernetes,
we can achieve local similarities
even on the developer's machine.
Applications in the cloud native world
are stateless by design.
We almost always have multiple instances
of our application running
on essentially ephemeral infrastructure.
So maintaining state and sessions in the application itself
would be counterproductive to say the least.
Because of the ephemeral nature of cloud infrastructure,
the reality is nodes die all the time.
Having applications that start up rapidly
and handle termination gracefully,
added to the concurrency mentioned above,
will provide us a highly available system.
Add into this geographical distribution
through availability zones, or even regions,
and you have the recipe
for a highly available distributed system.
One of the biggest lessons of cloud native computing
was the importance of having configuration
injected into the environment.
This allows us to build apps that can be deployed anywhere
with local service dependencies without any hard coding.
We also can inject secrets to our applications
in the same way to further separate the concerns
of our applications from the potential security risks
of password leaking.
Observability must be a first class thought
of every application.
In the enterprise monolithic world,
developers often didn't think a lot about what it meant
to evaluate the state of the application when it was running
because it was somebody else's job.
Cloud native applications
put observability at the forefront.
I have, for instance, started worrying about observability
in the ideation and design phase of every single system
as well as application within those systems.
When building Spring applications for Kubernetes,
there are some things I believe you need to consider
and have plans for.
I'm going to share with you some of my opinions
so you know them up front before we start coding.
The first consideration
that I believe takes some initial thought
is how you will handle environment variables
for Spring properties.
You have many options.
You can inject them into your docker files
and translate them there to JVM arguments.
You can leverage the Spring properties
directly in your environment configuration.
Or you can do what I will show you,
which is to leverage standard environment variables
and their naming conventions
and then port them to Spring properties
in your application.properties file.
Logging is another area you have to consider
because most log shippers we leverage
with Kubernetes-based run times
work best with JSON formatted logs.
This is an easy aspect to solve with Spring,
but it's something you have to consider early on
in your development processes.
In addition, building common taxonomy of tags in your logs
is worth the effort regardless of the language
or patterns being used.
Telemetry is another big area of thought.
Again, common taxonomy that is hopefully shared
with your logging systems taxonomy is very important.
But, the use of technology is also important.
I prefer to keep my apps pure open source when possible
and leverage technology like OpenTelemetry
to instrument my applications,
but having well-instrumented applications
is the most important part.
You can leverage a lot from Spring here
with their ops system integration,
but don't make this an afterthought.
Security applies to so many layers
when building applications.
It starts with how we develop our applications,
moves to how we integrate with our authentication
and authorization workloads,
and then expands to even how we build our images.
We're going to spend a lot of time
talking about building images
and I will share with you my thoughts there.
When building applications for Kubernetes,
I subscribe to the 15-factor thought
that authentication should be validated at ingress
and authorization validated throughout.
We aren't going to get into this area much in this course,
but I have a course here in the LinkedIn Learning Library
on Spring security that you can leverage.