♪♪
-Hi, everybody. Welcome to my "Deploy" talk.
The title is "Combining Cloud Native and PaaS:
the DigitalOcean App Platform."
My name is Steven Normore.
I'm an engineering manager at DigitalOcean
currently working on the App Platform product,
previously the managed Kubernetes product
and container registry.
The premise of this talk is that the DigitalOcean App Platform
is a managed application PaaS that abstracts
and encodes best practices of building
and operating cloud-native Web applications.
And I'll spend the rest of this talk
describing what this means
and hopefully convincing you that it is the case.
We'll start out by describing what PaaS is
and how it compares to IaaS.
We'll dive into what cloud native is,
the 12-Factor Application methodology,
principles of each, and some benefits.
And then we'll move to the DigitalOcean App Platform,
how exactly it is a cloud-native PaaS
that encodes best practices.
We'll talk briefly about how it's also built
on cloud-native technologies.
And then we'll end the talk with some takeaways and guidance...
...for building on the App Platform going forward.
So what is PaaS, and how does it compare to IaaS?
PaaS stands for "platform as a service,"
and IaaS stands for "infrastructure as a service,"
which you probably already know.
PaaS is a cloud-computing platform
that abstracts away infrastructure details,
like servers, operating systems, storage, networking,
scaling, and monitoring
so that developers and businesses
can focus on building their applications.
You can see that the focus of PaaS
is on applications and data
while abstracting away runtimes, operating systems,
virtualization, servers, storage, and networking.
So now let's jump to cloud native
and cloud-native applications.
There are four main tenets of cloud-native applications.
They are continuous delivery, containers,
microservices, and DevOps.
And we'll spend some time
briefly talking about each.
Continuous delivery
allows you to release quickly, reliably, frequently,
and with less risk.
The idea here is that when you make changes to your codebase,
those changes are rolled out within minutes.
Containers provide a lightweight virtualization,
offering efficiency and reproducibility,
while abstracting away the underlying operating system.
Microservices encourage modular and loosely coupled services
communicating via API contracts that can be deployed
and scaled independently.
DevOps encourages collaboration
between software developers and operations
with the goal of automating delivery of software
and infrastructure changes.
There is some relation to continuous delivery here,
but with more focus on the collaboration
between developers and operations
and the automation that's produced from that.
So a few benefits of cloud-native applications
are faster time to market,
more agility,
right-sized scale and capacity,
collaboration, and rapid recovery.
So now let's jump over to 12-Factor Applications
and the 12-Factor methodology.
It's recommended that you do conform to the 12-
Factor methodology when building cloud-native applications,
and we'll talk a little bit about why
and go through each of the 12-Factor principles.
The 12-Factor methodology
provides declarative specifications
for setup automation, clean contracts
with underlying operating systems.
It's suitable for deployment on modern cloud platforms.
Encourages parity between development
and production environments
and can scale up without significant changes.
The 12 principles of the 12-Factor methodology
are codebase; dependencies;
config; backing services;
build, run, release; stateless processes;
port binding; concurrency; disposability;
dev/prod environment parity;
logs; and admin processes.
And so now we'll run through each of these
with a brief description and some benefits.
Starting with the first principle of codebase,
the idea is that your code is tracked
in a revision control system such as Git,
deployments are associated with specific code versions,
and that deployments are automatic.
Moving on to the principle of dependencies,
we should explicitly declare dependencies via a manifest.
We should isolate dependencies to avoid leaking
any that may be implicit.
The next principle of config
encourages us to store config in the environment
so that you may have a different configuration
across your environments.
You can use environment variables
as a mechanism to accomplish this.
The principle of backing services
are such that backing services are treated
as attached resources,
communicate through a clean API contract
with your backing services,
and they are decoupled from specific instances
so that you can swap them out for others
that conform to the same API contracts.
The next principle of build, release, run
encourages strict separation between build and run stages.
This ensures no changes can be made to code at runtime...
...and ensures that runtimes are identical
as processes scale.
The principle of stateless processes
tells us to execute apps as one or more stateless processes.
Data is persisted to a backing store.
This allows processes to scale without syncing state.
And the principle of port binding encourages
self-contained Web services
with the idea that you bind to a port passed
into the environment variable called PORT with all caps.
This is a common pattern
that you may already be familiar with.
This helps avoid reliance on runtime injection
of a Web server.
The principle of concurrency
encourages us to scale up via the process model.
We prefer horizontal scaling over vertical scaling.
So we prefer to scale out over scaling up.
This also encourages us
to break apps into modular components.
The principle of disposability encourages robustness
with fast startup and graceful shutdown,
as well as robustness against sudden crashes and failures.
This facilitates fast elastic scaling and rapid
and robust code deployment and config changes.
And the principle of dev/prod environment parity
encourages us to keep development,
staging, and production as similar as possible.
This minimizes time between coding and deploying...
...and also tells us that ideally
code authors and deployers should be the same people.
And the principle of logs
tells us to treat logs as event streams
that you write to standard out...
that apps are not responsible
for routing or storing their logs...
...and this facilitates self-contained apps
and minimizes dependencies.
And finally, the last principle
is of admin processes.
Encourages us to run admin
and management tasks as one-off processes...
to run against a specific release
in a specific runtime environment...
and that this admin code should be shipped
with application code.
in your version control system.
And a few benefits of the 12-Factor methodology
are that it minimizes time
and cost for new developers joining the project...
maximizes portability between execution environments...
removes the need for servers and system administration...
enables continuous delivery.
It optimizes for agility
and prioritizes performance and reliability.
So now let's move on to DigitalOcean's App Platform.
So the premise of this talk was that DigitalOcean's App Platform
is an application PaaS that encodes and abstracts
best practices of building and operating
cloud-native Web applications.
And I'll spend the next few slides describing
what exactly the application platform is composed of
and how that contributes...
...to that premise.
We have a declarative app specification.
You deploy your Web services,
static sites, background workers, and jobs.
You can integrate directly with DO managed databases.
And you have continuous delivery from your Git repositories.
You can auto-build with buildpacks
or bring your own Dockerfile.
We have built-in container health checks
and zero-downtime deployments...
built-in global CDN with SSL for all domains.
We have built-in ingress with path-based routing.
You can scale up and out easily and safely.
And we have built-in monitoring, alerting, and logging.
And so I'll spend the next few slides
going through each of these items
and talking about how they relate to cloud-native
and 12-Factor principles.
So, first, we have a declarative app specification.
This spec defines the desired state of your app.
You can clone, reuse, and share apps easily.
And this encourages parity
between your staging and production environments.
So we can also deploy Web services,
static sites, background workers,
and jobs as components within our app.
This means we can combine components to make a full app.
This encourages modular and loosely coupled components...
...enables components to scale independently...
and supports one-off admin and maintenance processes.
We also have continuous delivery from Git repositories
so that you can build and deploy
from a codebase with revision control.
You can build, release, run with decoupled build and run stages.
And we have parity between environments
through continuous delivery.
This also encourages DevOps by abstracting away
the CI/CD infrastructure.
We also have auto-build with buildpacks, or you
can bring your own Dockerfile.
This means you can build and run stateless containers.
This encourages decoupled environment config...
and parity between environments through build strategies --
through your shared build strategies.
This also lets you get started very quickly.
We have built-in container health checks
with zero-downtime deployments.
We accomplished zero-downtime deployments
using rolling updates Kubernetes-style.
We support continuous delivery.
And this provides a robustness
against app failure and degradation.
We have a built-in global CDN with SSL for all domains.
So we have a global CDN for components
such as Web services and static sites.
We have SSL for all domains as the default.
You can also bring your own custom domains,
which will also get SSL
as the default.
The CDN provides DDoS protection as a built-in feature.
We also have a built-in ingress with path-based routing...
which means you can route to app services
based on URL path behind the same domain.
We load-balance across multiple instances of your services
for high availability, and this encourages
and supports breaking your app into modular services.
You can scale up and out easily and very safely.
You scale vertically or horizontally as needed.
You scale components independently.
And we have zero-downtime scaling with health checks.
We have built-in monitoring, alerting, and logging.
Logs from container standard out and standard error
are available via the API, as well as the UI.
Insights and alerting for app containers and ingress...
...including CPU and memory usage for containers,
as well as bandwidth, throughput, and latency
for the CDN and ingress.
Apps are not responsible
for managing their logs or metrics.
So not only is the App Platform
built to encode and abstract the best practices of building
and operating cloud-native Web applications --
We've also built the App Platform
on many cloud-native technologies.
We run on a fleet
of multi-tenant Kubernetes clusters.
These are multi-tenant DO Kubernetes clusters
that you can use today as a customer yourself, as well.
We have workload isolation using a tool called gVisor
and network isolation
using a tool called Cilium, among a few other things.
We do auto-build using cloud-native buildpacks,
or we build your Dockerfile using Kaniko.
We have a global CDN with SSL for all
using Cloudflare, and we accomplish the ingress
with path-based routing using Istio and Envoy.
We have app monitoring and alerting using Prometheus
and app logging via Fluent Bit.
We choose the best available open technologies
so you don't have to worry about the evaluation yourself.
And so we'll end this talk with some takeaways and guidance
for building your applications
on the DigitalOcean App Platform going forward.
You should keep in mind
that your app components are stateless.
And remember that local disk is ephemeral.
You should break your app into modular components.
And you should inject your config as environment variables.
Remember that services can bind to the port defined
by the environment variable called PORT with all caps.
And if you want more control over your build process,
you can bring your own Dockerfile.
And that's it. Thank you very much.
You can get in touch @snormore on Twitter or GitHub.
Have a great day.