Building applications had rapidly become the easy part of development. Whether on the web or mobile, these applications need a place to live, and that place is constantly changing. From local servers in closets to colocation facilities to the cloud, we’ve seen rapid change over just the last few years. Now we have containers and the idea of cloud-native development.

But what does this mean?

Around the world, companies are transitioning to microservices and the container architecture. But that move should come with a few considerations — not just a blind jump to “the new hotness.”

We like to think there are at least five important elements teams should consider when getting started with Docker and Kubernetes, and whether the move is right and fits with the organization’s needs for application deployment.

Architectural stability
Cloud native, and the container movement, are relatively new concepts. As we mentioned, just a few years ago, running one’s own servers in a closet was the accepted method of application hosting. Remember IIS?

At its core, cloud native is the philosophy behind Docker and Kubernetes. It’s the manifesto that informed the concepts behind containers and other parts of the cloud world. It’s an umbrella for a set of tools — often open source — built to help applications deploy succinctly.

This means dealing with consistent growth and change, which also can lead to fragmentation within the ecosystem.

Free-for-all development of containers
“Although tools [in the container ecosystem] are very useful, they are also insufficient,” as Brendan Burns, creator of Kubernetes, said in his talk at GOTO Amsterdam. This is an indicator of the need to find balance within a company or organization taking advantage of containers and cloud native.

There are stable pieces of technology available, things such as Platform as a Service for containers. But many developers believe in building things themselves. This is a major cause of fragmentation of the mainstream pieces in the container ecosystem.

There is value to working on a company’s personal flavor, though sometimes the standard tool is the best answer for the team. This is something that will settle over time.

Do I even need Docker/Kubernetes?
Cloud native is still a buzzword as far as deployment techniques are concerned. Developers are always the early adopters and the drivers of an organization using technologies like Docker and Kubernetes, but it is by far not universal.

Considerations such as security, maintenance of the application, and team adoption should be part of a development crew’s decision process when starting with a new technology. As we see the DevOps philosophy grow alongside the cloud native concepts, we see the growth of microservices, and our teams will need to be familiar with all those ideas. Key factors such as observability and monitoring will need to be integrated into the team’s workflow.

Adopting microservices architecture
Most applications in productions are still monoliths — large applications with old code, hardly refactored in recent memory, and completely unable to deploy using Docker or Kubernetes.

Our developers should be driving the bus when it comes to fixing the issues to prepare our monolith for the microservices style of cloud native. No one is saying a complete rewrite is necessary, but deploying a monolith is probably difficult regardless of the method.

Are the big kids playing yet?
While Microsoft’s Azure team is heavily involved in Kubernetes, there aren’t many large-scale organizations making the leap. Older technology organizations aren’t jumping in yet or adopting cloud native ideals. As with most tech, they will move slowly and cloud native may be bypassed for the next technological shift.

That said, cloud providers such as Pivotal and Heptio were born in the cloud native philosophy. Faster moving large companies like Google and Microsoft were positioned to move. These are the likely players that will drive the movement forward in a direction benefiting everyone along for the ride.

History will inform us if cloud native is to become the adopted default of modern DevOps culture, or if containers will become the next step in a world of ever-changing technical merit. While we continue to see more applications using containerization and cloud native philosophies, these issues should resolve themselves — at least, that’s our hope as an application-building community.