Serverless computing is the final frontier in scalable computing

Warning: this post is forward looking and does not give easy answers.

Cloud computing continues to enable innovation in the way we develop and deploy software.

Service Oriented Architecture (or SOA) is a software development paradigm for breaking up large systems into more manageable independent components. This probably got off in the nineties. As a matter of fact I worked on the architecture of a travel information system along those lines at the time.

Then we moved into multi-tier client server architectures, where a farm of web servers talks to a farm of application and database servers.

These days micro-services are the rage, each implementing a specific API to enable event driven software for full responsiveness.

However, micro-services still need to be deployed on compute units. This is one of the reasons why containers such as Docker’s are becoming so popular: they are much quicker to scale than virtual machine instances.

Yet, you are still deploying on discrete compute units. And while being able to scale up your resources is key to the cloud computing benefits, scaling down below the level of a compute unit makes it possible to think in terms of lots of smaller micro services. Maybe we should call them nano services.

The notion of the server, even if it is a container, then disappears, and the minimum cost for running a service drops from a dollar a day or so to millicents.

AWS Lambda is a new platform that enables this serverless computation style. The basic unit of deployment is a piece of code that handles one API request that can last no longer than a few seconds. The AWS platform does the replication and scaling. And billing of course, you can trust Amazon to do that :-).

The idea is not entirely new. Google App Engine did something similar 5 years ago, when I started measuring the cloud. However, it was too far out, lacked certain features to make it easy to use and deploy. In the meantime, it has made big steps, and Google App Engine  certainly remains an option in this space.

What is the strategic implication? This serverless computing style revolutionizes application architecture. We can now really start thinking in terms of service orientation and grid style computation, without being distracted by our target server architecture. At the same time, this requires significant reengineering of even the most advanced DevOps continuous deployment toolchains. And finally, security and risk management need to make some ‘adjustments’ in their thinking, to say the least.

IT Innovation and the bleeding edge

This is the sequel to my introductory post “IT leadership in the 21st century“.

IT Innovation and the bleeding edge

When IT is being used to drive innovation, it is by definition on the ‘bleeding edge’. This is because proven technology is in wide use, and it will not lead to much competitive advantage. There is nothing wrong with proven technology. It just does not give you that leading edge.

There is a lot of proven technology in IT. We quite know how to build reliable hardware, and a lot of software layers have been battle tested for decades. The core of much of server land out there is Linux, which is a remake of a remake of Unix, which was in its 10th edition when I worked for a while at AT&T Bell Labs in 1986. It would be an understatement to say that we sort of know how a good operating system kernel should look like. Even so, we are still regularly exposed to security bugs.

In programming languages the innovation is more recent. When I went to university Java was not yet invented. It is considered old school now. New programming languages still pop up in production, one example being Go (or golang) as developed at Google in 2009 (incidentally by people that I met at Bell Labs more than 30 years earlier).

Beyond programming languages we see innovation in the software delivery and deployment. Docker is the rage now, but it is not the end game.

You don’t need a lot of IT leadership for proven technology. There are no hard choices to make. You can just do what your peers do, or ask your supplier. And if you are on the bleeding edge, it is best to base that on proven technology as much as possible.

Real digital innovation takes real digital leadership

But real digital innovation takes real digital leadership. And this leadership has to both understand the business requirements as well as the entire path to the programmer who presses a button to deploy as well as the path from there to the customer’s screen. Of course, you need not understand every detail about it, but it pays to understand the general concepts, trade-offs and risks.

And generally speaking, right now the benefit is in feature velocity and the main risks are twofold. The first risk is in your own competence, the second is in smart adversaries hacking your system for personal data.

This is the new ground to break. That is the bleeding edge.

 

More in a next post at which point we have to consider the social and organizational dimension of innovating with and within IT.

Business Model Canvas for Cloud Providers

Cloud Computing is not so much about technology but more about the new business models that this technology enables. The question then is, how do these business models look? One of the most inspiring ways of looking at business models is through the so-called “Business Model Canvas”. This article explores the basics of cloud computing business models as drawn out on such a canvas.

Business Model Canvas

The business model canvas is a visual template for developing and discussing business models. For more information see http://en.wikipedia.org/wiki/Business_Model_Canvas and http://www.businessmodelgeneration.com/

AWS EC2 cloud canvas

The business model canvas has nine basic building blocks and specific relations between those building blocks. The rest of this article describes each of them, and gives a brief example of how they apply to a cloud provider proposition. The main cloud provider example I will use is Amazon Web Services (AWS), in particular EC2 (virtual machines on demand). This is an Infrastructure as a Service offering. The power of the business model canvas approach will become clear if we see how it can distinguish between various cloud service offerings and traditional IT.

Customer segments (CS)

In the Business Model Canvas, “Customer Segments” are the groups of customers that the company ultimately serves, i.e. the ones that consume and pay for the services.

In the AWS case, although basically anybody with a credit card can spin up a virtual machine, it looks like Amazon is primarily targeting software developers and (startup) SaaS providers as its main customers. Historically, Amazon development teams were the first customers. External customers were initially added as an afterthought.

Value Propositions (VP)

The value propositions reflect the customer’s problems and needs. This is the central element that describes why a customer would ultimately pay for the product or service.

The value proposition of cloud computing centres around its five essential characteristics. For example, in the AWS EC2 case, the core component of the value proposition is rapid self-service provisioning of virtual machines with pay per use billing. For each individual customer this translates into different business advantages. An example is reduced capital expenditure and reduced risk of over-investing or under-provisioning.

Channels (CH)

Value propositions are delivered to customers through communications, distribution and sales channels.

It is often assumed that cloud computing relies solely on self-service direct sales, but the reality is much more diverse. SaaS providers in particular are developing extensive partner programs.

AWS primarily employs a self-service direct model, where the delivery is through APIs. AWS also provides a web user interface to those APIs. Interestingly, that interface used to lag in functionality behind the main AWS services, but these days most new features are announced on the API and the Web UI simultaneously. The model is enhanced by premium support.

Customer Relationships (CR)

Customer relations are established and maintained with each specific customer segment.

One of the ways that AWS maintains relationships with its customer segments is through conferences. The 2013 re:Invent developer conference attracted 9000 visitors. Additionally, there are vibrant online communities. Finally, though details are scarce, we can assume that AWS does extensive analytics on the activities customers engage in on the platform.

Revenue Streams (RS)

Revenue streams are the result of value propositions that are successfully offered to customers.

The structure of revenue streams is where cloud computing differs from earlier IT service models, as they are usage based rather than asset based.
AWS basically charges hourly fees per virtual machine. The ‘bigger’ the virtual machine, the higher the hourly rate.

Key Resources (KR)

Key resources are the assets required to offer and deliver the previously mentioned elements (e.g. value proposition, customer relationships).

AWS owns massive amounts of hardware, estimated at 1 million servers or more. That is housed in dozens of data-centres worldwide. But there is more; the service can only be delivered through advanced and unique fulfilment software and processes. Amazon must have invested substantially in that.

Key Activities (KA)

The key resources perform key activities.

At AWS the key activity, delivery, is highly automated. But at the scale of AWS, oversight and resource planning is still a serious effort. Optimizing assets versus utilization is essential in the IaaS business model. Through economies of scale, AWS is able to spend a lot of effort on these activities.

Key Partnerships (KP)

Some activities are outsourced, and some resources are acquired outside the enterprise.

AWS buys immense amounts of hardware, and uses a lot of (open source) software. Building of data centres is also likely to be outsourced.

Cost Structure (CS)

All business model elements result in a cost structure.

In more traditional IT service models the revenue streams are tightly coupled to the cost structure. The cloud computing innovation is also about decoupling these.
At AWS the main cost elements are in assets such as servers and data centres; in services such as electrical power and telecommunications; and in people for developing and managing the systems.

Summary

The business model canvas is a good tool to map out the particularities of cloud provider business models. In this article we have only looked at the basics of a particular infrastructure provider. For software-as-a-service providers, cloud brokers, or internal/private cloud providers, the canvas can also be used to discuss their differences.

What does your business model look like? Let me know your questions. And if you want to do this for your own organization, consider my Cloud Business Essentials workshop.

Which Cloud service model is right for you?

Cloud Computing is no longer an option, but a reality in the IT landscape of almost all organizations. At the same time cloud computing has a lot of variants and choices. These choices are relevant for the IT strategy, and in some cases even the company strategy.

This article outlines in a step by step way the most important questions that you can ask to come to the right cloud strategy.

The first question is: what to expect of cloud computing? Which business improvements do you aim for? Cost advantage? Agility? Mobility? Innovation? If you don’t have a clear idea on this, it may be sensible to first dive into cloud characteristics, models, options and alternatives.

infographic cloud service model

The next question to ask yourself is this: which IT applications and functionality are the most important ones for your organisation? What is most needed in IT, now and in the future? Is that e-mail, ERP, CRM, a big website, or something else?

With this overview, you can ask yourself the central question, the one question that has a fundamental impact on your strategic cloud choice. And that question is: are these important applications unique for your organization? Do they make the organization into what it truly is, are they nowhere else to be found, are they of vital importance?

If the answer to this question is ‘no, these applications are not uniquely important to my organisation’, this means that the core competence of your organisation is not in IT. That is not a bad thing, you can be a very successful 5 star restaurant, or a manufacturer of advanced pumps for the process industry, without having unique software. In that case, having your own hardware is senseless, in the long run. It may take a while for the software market to realize this, but you are ultimately a SaaS ‘consumer’.

Star restaurant or not, as a ‘SaaS consumer’ the most important IT competence is selecting and implementing SaaS offers. Depending on the type of company this also requires quite a bit of IT competence, but that will be the topic of a later article.

If the answer is: ‘yes, my software is very unique, i cannot get it elsewhere’, then new opportunities arise. Your software and the associated data is a ‘strategic asset’. It would be a waste to only use it for your own company. There are probably other organisations who could also benefit from this software. If you are not directly competing with them, you could be their SaaS provider.

You should also consider giving your partners in the supply chain (customers, suppliers, etc) access to that software to enable them to do their work better, and to generate new business. This is in line with the practice of certain insurance companies: they give their agents direct access to their policy database. It is even thinkable that there are start-ups that would love to innovate with that strategic software. Procter and Gamble, for example, has opened up its research database to enable innovation by outside companies. As a result the percentage of patents that are actually used in products has risen from 10% to more than 50%. As early as the 1960s, American Airlines set up the SABRE flight information and reservation system that was used by travel agencies and other airlines.

My proposition is this: if you have strategic software assets, you also want to be a cloud provider for that software.

So, as a provider of software services (SaaS), what are your strategic options? Unless you have a substantial and constant workload it is not very sensible to purchase a lot of servers and associated hardware. The more obvious approach is then to procure your servers in an IaaS model (Infrastructure as a Service). This has the disadvantage that your system administrators, in collaboration with your software developers have to have substantial expertise in software scalability. You will have to deal with choices around multi-tenancy architectures, and detailed capacity and performance management. It may be worth your while, but there are quite a few alternatives these days.

Instead of IaaS, you can also focus on a PaaS (Platform as a Service) strategy. Scalability of the architecture is then no longer an issue for the developers. One disadvantage of this strategic choice is the potential for ‘vendor lock-in’ if the software is not easily ported to a different PaaS provider. This will then be something to address in the software architecture.

An example of this approach is the website that was built in 2011 for the British Royal Wedding. It was developed and deployed on Google App Engine. The scalability of the website was very important, and could be guaranteed easily with this design choice. For a website of this type, vendor lock-in is also not very hard to avoid. Most of the content is fairly static, functionality is limited, and the lifetime of the website is also short.

A few other strategic design choices for the cloud provider have to do with the degree to which services of other cloud providers can be used. For starters, you can ask yourself if you want to go to market all by yourself, or that you want to work with a ‘broker’ who includes your service in his portal (which is like an app store). That too has implications for your software architecture, because the portal can assume some of your functionality, like customer registration.

Finally, once again, it is a good idea to ask yourself which part of your functionality is truly unique. As an example, if you are a start-up companies it does not appear to be very distinguishing to develop your own software for helpdesk, payments and identity management.

In summary, cloud computing offers a lot of opportunity for setting up IT and positioning an organisation for a bright digital future. But doing it all by yourself is only rarely the best plan..

Interested in finding out more? Find yourself a relevant cloud training or workshop, or contact me directly.