Cloud platform services continue to expand. There is a growing opportunity to accelerate application development with Platform-as-a-Service (PaaS) offerings. Some organizations take advantage of these to cut down coding and dealing with application infrastructure. Others… not so much. The old Not-Invented-Here syndrome is alive and well.
Well-established technology teams often don’t like to buy things if they can build them. A frequent response is that they can build things better, faster and less expensive. In other words: invent them.
Of course, PaaS options are not right for every solution. But a decision to stay with traditional models should not be based on a desire to invent application infrastructure in-house. It’s more productive to innovate business solutions instead.
The Cloud Services Spectrum
There are many shades of PaaS models on the spectrum between basic Infrastructure-as-a-Service (IaaS, spinning up virtual machines) and Software-as-a-Service (SaaS, running shared business applications):
- Container services do away with the distinction between the application runtime and the operating system. Examples: Docker containers and Kubernetes orchestration.
- High-control application environments pre-package all runtime components to execute applications. Developers can use common programming languages. Examples: AWS Elastic Beanstalk, Azure Cloud Services.
- High-control serverless platforms provide combine all infrastructure into a runtime environment for services or micro-services. Developers can still use common programming languages. Examples: AWS Lambda, Azure Functions.
- High-productivity application platforms offer “low code” services, accelerating development. These platforms use various degrees of visual drag-and-drop development. They have a higher degree of vendor lock-in for code, but there is less code overall. Examples: Mendix, Outsystems, Salesforce Lightning.
- High-productivity model-driven platforms with “no code” services, further accelerating development. These platforms further reduce application code but increase vendor lock-in. Example: Betty Blocks.
This illustration highlights the PaaS models on the cloud services spectrum and shows the degree of the Not-Invented-Here syndrome:
Not-Invented-Here
As the scope of provider-managed PaaS services increases, the amount of custom developed application code decreases. So does the amount of control over the implementation of the solution. It is no surprise that cases of the Non-Invented-Here syndrome increase along the way.
The core question is: what does the organization need to invent for a particular solution?
To answer this, we ask more questions:
- Is the “plumbing” a differentiator, or is it a commodity?
- Will the solution work well with the inherent style of a PaaS?
- What is the trade-off between control versus productivity?
- How important is the risk of vendor lock-in versus faster time-to-market?
- How do the initial and long-term cost stack up?
- What skills does the organization have?
- What is the benefit of an evergreen technology approach?
- What is the longevity of the cloud service versus the lifespan of the solution?
- How does the existing and target ecosystem play into this?
Note that none of these directly ask “how do the architecture and development teams feel about inventing application infrastructure?”
Go on and invent business solutions
As a rule of thumb, you want to spend the least amount of time, effort and money on technology that is not differentiating. For many customer-focused and internal business systems, there is little to gain in inventing a better spring mechanism for the mousetrap. So it makes sense to consider PaaS solutions that come with pre-built lego blocks.
In other cases, the innovation may be at lower levels. For a product organization developing the next-gen video streaming or messaging platform, the underpinnings of the solution can make an enormous difference.
In summary, invent where it makes a difference, and steal* everything else.
*while paying applicable PaaS subscription fees
Ernst Rampen ©2018
