Containerization of APIs and apps
Containers
As opposed to virtual machines, containers are easier to configure, package and manage, although some can argue they also have a learning curve and some software pre-requirements. But they have quite some advantages:
Containers are portable
Because containers bundle together everything you need to run an application, from the operating system to any 1P or 3P dependency, you can run them anywhere.
Containers are secure
Containers provide a high level of isolation for workloads, by virtualizing hardware capabilities that a machine needs to run software, like CPU, RAM, hard disk capacity, etc. That makes containers secure, because they are isolated from the host machine, and other containers when they exist.
Container images
Container images are basically the read-only blueprint that defines container instances built from a that image. Because they are portable, they can be shared, allowing developers to quickly get started with all they need to start working.
When I got my first enterprise gig, I remember how difficult it was to get started. Local environment configuration could take hours or days, to install everything you needed to start working.
Containers learning curve
Working with containers can be challenging, if you’re the one setting them up and managing them. Luckily, containers also enable a great separation of concerns: application developers focus on the application, and operations teams focus on the infrastructure. This is also one of the principles of cloud-native development.
Fully managed PaaS and containers
When you’re building and deploying your application to a fully-managed PaaS, you’re very likely effectively deploying your app to a container, that is built with the configuration you provide, and that is managed by the PaaS provider team.