For years, PaaS has been touted as the ultimate solution for developers. Push code and get out of the way - PaaS will take care of the rest. Deploying to a PaaS is easy, but customization requires moving to a DIY PaaS solution. Without a PaaS, developers are stuck performing tedious scripting on top of cloud infrastructure.
So, what's a software-driven company to do in order to choose a deployment strategy that is easy, yet customizable? We think there's another option to the PaaS decision. First, we need to revisit the reason for PaaS from the perspective that counts: the needs of the developer.
What developers really want out of a PaaS
Most developers don't want to think about servers, server configuration management, or network configuration. Instead, they want to be able to deploy ideas quickly to try something out, with minimal friction. At this end of the spectrum, developers need:
- One-step git push to deploy applications
- Rapid provisioning of databases and other resources
- Automated linking of provisioned resources
This is where public PaaS has gained the most traction with developers for simple, monolithic applications.
On the other end of the spectrum, developers also want to know that as their application matures, the PaaS solution will too:
- Offer advanced security through more complex networking rules
- Quickly scale and in a cost-effective manner when using cloud native resources
- Support robust architecture styles, such as SOA, microservices, and event-driven, as a single stack rather than separate projects wired together manually
- Make it easy to monitor and troubleshoot problems across any number of deployed instances and services
Public PaaS cannot deliver on these requirements. This is why companies have been looking toward DIY PaaS to fill this gap. Developers deploying to DIY PaaS are excited about the potential for ease-of-development and flexiblity. But what does it mean for the business to adopt a DIY PaaS solution?
Developers caught at the intersection of IaaS, public PaaS, and DIY PaaS
Companies taking the leap into PaaS often opt for trying a public provider. Initially, the results are positive, proving easy deployment of early stage applications. But as applications mature they quickly run into the problems of cost, limited security options, and lack of flexibility.
As a result, companies have started to explore the idea of building their own PaaS to meet developer needs. However, building a PaaS isn't as easy as it seems to be. As companies start to embark on the journey of DIY PaaS, they're learning the cost of DIY PaaS is high. The cost and time required, often outweighs the potential for increased agility.
So, developers are caught in the middle:
- Requiring teams to provision and configure servers is time consuming, leads to inefficient use of company resources, and distracts teams from focusing on the core product
- Public PaaS provides rapid deployment for experimentation without investment in infrastructure but at the expense of longer-term flexibility
- DIY PaaS provides more flexibility, but adds an expensive burden to the business that can be a distraction to their core capabilities
Selecting the wrong approach can have a negative impact on developer productivity and even their longevity as an employee. If a developer's code never sees the light of day (or takes much longer to get there), they will move to another company that allows them more efficiency and freedom. In fact, as this article was being drafted, Nati Shalom from Gigaspaces wrote about similar concerns.
While it may be tempting to do so, software-based companies shouldn't allow themselves to get into the business of building their own PaaS. Instead, the focus should be about optimizing for the needs of developers, while focusing on delivering the business capabilities it knows best.
So which PaaS option is the answer? Perhaps the problem is with the limitations of the PaaS options available. What if we looked at a different way to approach the problem?
For developers, PaaS isn't really the answer
Perhaps the answer isn't which PaaS option is best: public or DIY. Instead, perhaps the focus should move toward a cost-effective way of meeting the needs of the developer at both ends of the spectrum: ease of use in the early stages of application development, and flexibility as the application matures. This is where DevOps as a Service offers an answer.
DevOps as a Service allow developers to easily deploy applications to the company's existing cloud infrastructure provider. Unlike public PaaS, DevOps as a Service is completely flexible while offering ease-of-use that requires just a little more initial configuration effort. Advanced options often include continuous release support, rolling upgrades, and complex routing and network management. All without the need to build scripts for server configuration or complex container-based deployment workflows.
Yet, DevOps as a Service remains flexible for supporting custom deployment workflows via an API when the need arises. Many services, including Cloud 66, even support deploying to your own hardware alongside cloud infrastructure for a hybrid cloud approach.
Developers don't want to be in the business of server and network configuration. They need something as easy as public PaaS, without the expensive overhead that comes with the flexibility of a DIY PaaS. DevOps as a Service may be the answer that meets the needs of developers throughout the application lifecycle.