Manage Learn to apply best practices and optimize your operations.

How to choose from cloud deployment models to fit your needs

When it comes to deploying applications in the cloud, this expert believes companies should be moving to full-stack deployment and considering PaaS as new apps come into play.

Cloud applications give companies the ability to adopt all sorts of development and release processes. Modern development...

approaches can deliver functionality to customers within minutes of it being coded. At times, the number of tools and approaches to make this happen is overwhelming. But there is good news. There are three fairly uniform approaches to deploying applications in the cloud:

These cloud deployment models are accompanied by the following environment types:

  • Hybrid: local development
  • All-in-cloud: all cloud environments

The basic assumption is that these cloud deployment models are driven by release automation platforms, and possibly scripted infrastructure and orchestration tools.

A review of cloud deployment models

I have ordered the cloud deployment models from most mature/adoption to least mature/adoption. As we move down the chain, a few things happen: release frequency increases and infrastructure considerations decrease. But many argue that control and security decrease as well. This is more a factor of the newer approaches being misunderstood than it is a reality. Let's look at each of the cloud deployment models in more detail.

Static infrastructure: In this scenario, code is built and deployed to infrastructure that is configured in advance and, for the most part, untouched since previous deployments. Infrequent configuration changes are made on existing infrastructure. And new releases replace the currently running one. This gives development teams full control of the release process without involving IT, but it takes considerable time to get initial infrastructure. However, it dramatically affects a developer's ability to get infrastructure for development that closely resembles production. This is usually done on a request-by-request basis and often takes several weeks.

The biggest shift in cloud deployment models is from static to full-stack, but not in one fell swoop.

The benefit of such an approach is that it is well known and it fits more seamlessly into the hierarchy of existing development teams, where there is a clear segregation of duties between IT and Dev.

But the benefit of static infrastructure fitting into existing infrastructure is also problematic. In this case, there is an isolation that is not conducive to DevOps. It encourages stagnation, and you could argue that DevOps is not possible in such a setup. The other problem is that separating infrastructure from code encourages pollution of environments over time, incurs a large effort and time cost for things like getting new frameworks installed -- and it does not support the increasing complexity of modern applications.

Full-stack: With full-stack deployments, applications are considered as their entire stack: a combination of virtual machine (VM), operating system, system configuration and code. The deployment process includes infrastructure. And each build is done on a fresh VM or container based on a predefined gold master image or script. Once the infrastructure and code is deployed, application traffic is switched from the old deployment to the new, and the old infrastructure is torn down. This is the principle; in practice, not all companies maintain the ideal approach.

Full-stack assumes some sort of container technology, which could be VMs or Docker containers. Docker is the predominant approach to full-stack deployments. However, with advancements in hypervisors, even delivering whole VMs is a reasonable deployment strategy; it's just significantly slower.

The benefits of full-stack deployments are numerous:

  • Consistency: By treating applications as the entire stack, you know that from the point of development to production, the relationship to code and configuration is predictable. You can also say with confidence what is on the servers in production. But image sprawl and unique configurations plague many cloud deployments because it is so easy to create new instances.
  • Speed: Full-stack deployments streamline packaging of applications, which allows continuous pipelines to be executed without the assimilation of people and configurations manually.
  • Finding bugs: Application bugs associated with configurations are easier to track down earlier in the pipeline. These are some of the most complex issues to address, and often require IT to get involved in things they need not.

The biggest issue with full-stack deployments is not the approach. It is the organization's ability to execute on it -- and the team's ability to communicate effectively and efficiently enough to allow it to happen. If IT is still isolated from development, and there is no DevOps function to vet and manage the standard configurations, full-stack initiatives are doomed to fail. But also there is the perceived issue of governance and security. Because developers roll their own infrastructure, if a full-stack deployment is not managed, they could unknowingly introduce unwanted consequences to production. But these issues are not insurmountable. The approach is well worth the effort, and if organizations do not do it from the beginning, they will pay for it later.

Born PaaS: With PaaS applications, the development team has zero infrastructure considerations. They instead pick from a buffet of cloud services that combine to provide a platform on which to deploy code. For example, with a Web application, the development team is given a location to deploy their code, usually a static host name for their instance. But they do not have direct access to the VM it runs on. And that VM may change from time to time at the discretion of the vendor managing the data center. All you care about is the vendor's service-level agreement. For organizations that build their application PaaS from day one, this method offers the greatest amount of freedom and speed.

Applications are deployed to the environments they have designated, which could be limitless given the flexibility. In an ideal world, deployments are made to development and integration environments on a per commit/pull basis. When the application is ready, moving from environments is as easy as promoting it from one to the other. This also can happen automatically.

This approach allows developers to spend all their time on code. It is also the easiest way to implement continuous delivery processes without introducing a large set of additional tools to do so.

There are some challenges. The biggest is the ability to install components and frameworks. The cloud vendor provides an existing library of frameworks that can be installed. If yours is not there, you might be stuck. Another challenge occurs with large applications, or populations of applications, that share a unified back end. It is easy to step on toes in this scenario.

For now, PaaS applications are reserved for smaller startups. There are tactical reasons for this, but for the most part it is because it's more difficult to take an existing application from static infrastructure to all PaaS, then it is to go from static to full-stack.

Considerations for adopting a cloud deployment model

As stated earlier, static infrastructure and full-stack could run 100% on cloud or a combination of cloud and on premises. There are speed benefits to having a hybrid approach, especially when organizations choose to do many local builds, but biweekly production builds. PaaS applications assume 100% cloud for the entire pipeline.

I have seen applications that are some combination of infrastructure as a service and PaaS. Usually this is done by a separation of front end and back end, where you would see front ends running on managed infrastructure and the back-end databases running in a database as a service, which is just PaaS.

The biggest shift in cloud deployment models is from static to full-stack, but not in one fell swoop. It is not uncommon to see some combination of full-stack and static infrastructure. The most common of which is when development is controlling their own development infrastructure and using full-stack deployments on premises, and then when it comes to production releases deploying to existing static infrastructure. This allows development to control their own infrastructure destiny and maintain the split of responsibilities.

It is also not uncommon to stagger full-stack deployments where only major releases are done full-stack and incremental updates are done on existing infrastructure. I would argue this is not full-stack and a fast track back to Waterfall days.

I believe that today all organizations should be moving to full-stack deployment and, at least, considering PaaS as new applications and projects come into play. And as far as I can tell, the biggest challenge to adopting the more modern approach is not technical but organizational, and the comfort level found in controlling and managing your own infrastructure.

Next Steps

Are Docker containers best for cloud apps?

What to do before deploying cloud apps

Partnership offers app deployment platform

This was last published in December 2015

Dig Deeper on Cloud application development and deployment



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which cloud deployment model has your team found to be most effective?
We’ve been suing PaaS with great success until recently when the service provider stopped support for several of the tools and frameworks that our process relied on. Since then, we’ve gone to more of a full stack implementation, but it’s too soon to determine how successful that will be.
You hit on a key point about Born PaaS and the limits it puts on development by only including certain components and frameworks or, even worse, changing what components and frameworks it supports after you’ve started using them.