Startup Choices Rapidly Becoming Enterprise Choices


As I wrote on “The Three Freedoms of Cloud“, cloud is all about agility and speed.  A couple of stories both illustrate and enlarge this point through the adoption of serverless architectures

A Startup Volunteers to Be the Canary in the Code Mine

The first story comes from a startup called Siftr (You know they are a startup because they could only afford one vowel).

The post is on the value of serverless as experienced by a small startup. They chose Google App Engine for their application.  Here’s the relevant quote.

An enterprise, with practically infinite resources at disposal, can afford to be selective about every single component that goes into their tech stack and can recreate the entire wheel. However, for startups, time is gold! Their choice of technology should help them maximize their number of ‘build-&-measure’ iterations and yet should never hinder the product design.

Source: Why choose Google AppEngine for starting-up — Technology @ Siftr — Medium

As a past startup guy, I completely lived this reality.

When I started newScale, we faced a choice of what to use to develop our product. Only three engineers, a short runway of cash, and lack of clarity about our market.  Job one has to be product / market fit.

At the time Java was not really an economic or performant choice ($300K for an app server was the quote from WebLogic; I didn’t see the logic of buying).  C++ (we came from that world) was too complicated, slow and lacked portability, and Perl and those type of languages were unknown to us.

So we chose ColdFusion.

Over the years, I got so much grief for that choice and five years later we re-wrote the app (at great cost) in Java.  So was it the wrong choice?  NO!  That choice allowed to build a rich, enterprise level product, acquire major enterprise clients which let us raise $26M over two rounds.

It was thanks to that initial success that we could afford to re-write it

(New) Reality Arrives to the Enterprise: Fast Eats Big

Market advantages have become transient. The time in which an enterprise could build an effective wall against competitors is fast fading.  Enterprises have responded by beginning to adopt the tooling, practices, and culture of start ups to remain competitive

My friend James Staten, Chief Strategist for Cloud at Microsoft Azure, has some useful research to share regarding the value of moving to PaaS.

Sure, moving your applications to the cloud and adopting more agile DevOps methods will save you money and make your complex application deployments more efficient but if you want the really big gains, focus the majority of your developers back on coding. According to Forrester Consulting, the gains from doing so are massive.

PaaS value chart

Yes, re-hosting or even building cloud-native apps in VMs and containers will give you big gains in agility and cost savings but asking your developers to manage configurations, update the OS and middleware and pick the right virtual resources to support their apps (let alone manage the security of their deployments) is a distraction that cuts into their productivity.

And shares some pretty dramatic numbers about the economic impact.

How much, you ask? In its latest Total Economic Impact Study, Forrester Consulting interviewed a number of current customers of Azure’s PaaS services and concluded that concluded that migrating to PaaS from IaaS resulted in a 466% return on investment. For customers migrating from on-premises environments to PaaS, the return on investment can be even greater. Time to market also improved by as much as fifty percent, because of the efficiency and speed of deploying applications with PaaS services.

James works for Azure but I believe these type of results apply to serverless architectures as a whole. And to be clear, these savings do require the adoption of new operating models such as DevOps. Sticking to waterfall and ITIL won’t get you there.

Also Amazon Web Services

And not to leave Amazon Web Services out, in our Accenture Cloud Platform, we are using Lambda for certain  components.  Our entire system is composed of COTS (we don’t owncode), homegrown components written in Scala, web services from cloud vendors, and now new components written in Python using Lambda.  In other words, not atypical from what you’ll see in a large enterprise that has history and heritage in their infrastructure. Heritage sounds better than legacy.

The value we get is similar to what others are finding:  savings in time to market, flexibility and agility.  And improved costs and security in our case.   Yes, you have to live within the constraints of the underlying PaaS, but that discipline keeps us focused on building value.

But What if It’s the Wrong Choice?

There’s a fear in using these tools that they could be the wrong choice. Well, it could be and eventually it has to be re-platformed, but you’ll either know it quick enough to make a change, or it will be a long ways down the road after you

But if it helped achieve product market fit, time to market, validate market thesis and / or deliver competitive advantage, the fair answer should be: WHO CARES? The business objective has been achieved.

Also, the cost of re-writes and re-platforming is not what it used to be. The cost of constructing new apps has fallen to an all time low thanks to the availability of tools, open source, and web services. In many cases, it will be faster to re-write it than to fix it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s