The XaaS – everything as a service movement is quite considerable. When looking at successful internet companies today, you can notice that a substancial portion of them offer “something” as a service. In this small article I want to explore what that means and I will explain why I think that every piece of SW should be managed and brought to their users “as a service”.
The power of taking away the operations burden from your customers
As a software developer in my former roles I loved to use 3rd party libraries which make my life easier and encapsulate some of the functionality that I needed. Why implementing all by yourself? At the same time I wanted control of the compile, deployment and installation process to allow full test coverage and consistancy betwen system (dev, test, prod). Who is not afraid that some 3rd party incompatibility will break your system?
But as I moved into more complex scenarios, I figured that I would love to consume not only some smaller functionality as library or module but as micro service. With the introduction of mirco-services and the associated loose coupling (runtime dependancy only) the need to have full control of the compile, deploy and install steps for these 3rd party elements also moved away. I wanted to use functionality at runtime, while still making sure that it cannot break my system. And with this, beside the requirements of managaging runtime compatibility, the desire grew that somebody else should take care of the uptime and stability of that micro-service. When you wrote it, why don’t you also run it for me?
While this idea is still challanging when you work in embedded or local systems (however there are solutions for it, we discuss this later), with the internet and cloud computing revolution it became obvious that this concept of consuming fully managed functionality is a successful business pattern. Why? Because nobody is interested in operating a piece of SW that somebody else wrote, but everybody is interested in re-using the piece of SW the other person wrote (as long as you can trust it to operate in your favor).
In ealier days I was convinced that you can build a great business by providing the right libraries to developers so that they can integrate that SW into their applications. And yes, it is true, but you need to support the developers in how to operate it. But I think that functionality that is delivered as a service, fully managed, is even more powerfull. When you enable your customers to consume your functionality without requireing them to think about patching, scaling, securing, harden, optimizing for performance, optimizing for cost, monitor, analyze, debug,… this piece of software, then usage and adoption is so much easier. The value of the software that you provide increases dramatically, because it reduces the amount of time a developer needs to invest for using a feature massivly. You need to understand the feature set, the API and the service SLAs. That’s it.
The fear that remains is the – what happens when it does not work – question, when you are depending on 3rd party services. Here, I believe that in a “as a service” model, the situation is much better then in any other model, e.g. directly using 3rd party libraries at compile time. And this because you have SLAs and service API contracts. When things break, you know immediatly which part of the system is owned by whom. When using libraries, you will always first debug by yourself and the reach out to the provider when things are clearer. Maybe you configured it wrong? When consuming managed services, you may still configured it wrong but the areas of responsibility and associated support is much more organized.
Attributes of software defined services
When talking about XaaS, we most often find terms like “IaaS – Infrastructure as a service”, “PaaS – Platform as a Service” and “SaaS – Software as a service”. While all these terms have their own idea, I would like to generalize that into functionality that is provided to us in a fully managed way and is consumed through well defined interfaces. And it is purely SW driven. The problem with the terms infrastructure, platform and software is, they are to generic. Some call a messaging system “infrastructure”, others call it a “platform” and certainly it is “software”. For the discussions I had around these terms, I just learned to avoid them.
When developing a software solution or product, you will require a complete software stack that consists of everything from firmware, operating system, maybe containers or virtualization layers, databases, communication stacks, several frameworks and much more. The SW that you write is hopefully on a level that builds your differentiation factor, the one thing that does not exist yet. Most properbly, the amount of 3rd party software in your solution is somewhere between 80 and 95% (when you count firmware, OS, middleware all in). The question now is, how you consume this SW. Who is responsible for updating, patching, debugging, troubleshooting all the vast amount of 3rd party software? When you once debugged 3rd party libraries to find race condition bugs in it, you know it is not fun and takes a lot of time. Time you could spend on writing better business relevant code.
So, what are the attributes I would expect from a software defined service, in order to allow consuming it in the best possible way?
- All features are accessible through a well defined API
- The API is fully documented along with a API contract that explains valid input parameters, behavior depending on the input, guranteed performance on given input and other operational relevant behavior
- When I use the API compliant to the API documentation, all non-expected behavior is immediatly treated as a bug on the service provider side
- The API is versioned, so that new versions of the API may be made available without breaking my code
- New versions of the API are compatible to old versions unless explicitly stated
- Old API versions are not deprecated without at least 6 months of lead time.
- With money I can buy support and a gurantee to have old API versions operational for the next 20 years
- The service is always up, there is no downtime because of maintenance
- The service is either multi-tenant capable or is provided dedicated for me
- The service provides a clean tenant isolation and security concept that prevents cross-tenant data access and noisy neighbour scenarios.
- I can not break the service because I used it in the wrong way, but I may be throttled or denied to use it in this case
- I can have different levels of SLAs and support, with respective price positions
- I can tailor my SLAs (e.g. guranteed performance) with respective price positions
- I only pay what I use, based on consumption, amount of calls, amount of XYZ. This should be oriented at the value I draw from using the service
- I can receive detailed reports on when and how much I used the service and I get billed accordingly
- I have an insight on new features and developments that are coming, the roadmap, so that I can plan ahead and avoid unnecessary implementations on my side.
- I never need to think about any operational management of the service, it is all taken care of by the service provider. I just consume the functionality.
Of course, all this comes for a price. You may argue that a managed services are expensive to operate and consume, specifically in regards to a similar functionality that you could add to your application by using libraries, frameworks or platforms that you package and deploy with your application. The point is, in a XaaS model, the cost for operation is explicit and measureable while when you do package it with your application the cost is hidden in the many hours that you spend in downloading, installing, configuring, patching, monitoring,…. the 3rd party sofware. Only because you do not have to pay somebody else (external cost) it does not mean it is cheaper. Most proberbly the opposite is the case when you consider the opportunity cost that you spend your engineering hours with 3rd party SW instead with developing your own IP.
Appling the “as a Service” idea to the physical world
Many traditional business transition from a classic sell-by-unit business model into a more service oriented business model. And the reasons are the same as in the purely software defined world. Today’s buyers of machines, engines, motors, inverters, solar panels, wind turbines, …, they all do not want to own that thing but are interested in its product: manifactured pieces, horsepower hours, torque, electrical energy output,…
Managing spare parts, executing regular and predicted maintencance and keeping the machine running with a maximum in efficency and a minumum of downtime is not in the key interest of these people. Beacause of this, many companies based their business model not on actual unit-price selling but on the service contracts. Service for 10 or more years is the revenue driver in many hardware businesses (and also some SW businesses). With the XaaS idea, this turns away from the old idea into a customer oriented value generation business model. Cost of equipment is alligned with generated output, not with unit prices and fixed service cost.
The interface idea is the same, the machine (or physical product to be more generic) must be used in a certain way so that the provider can gurantee certain uptime and output. If something breakes, it is the provider who has to take care and no proof is required that the machine was maintained correctly. Maintenance is part of the service, it is in the responsibility of the service provider to operate the machine so that it maximizes the output for the user.
As it is in the software world, this concept is as powerfull in the pyhsical world. The challange however is, to enable a vendor to go into this model, because it requires a new way of contracting, marketing, selling, billing and to enable operations new IOT technology and Big Data Analytics need to be adopted. Not always an easy way to go.
Why also internal software should be managed and consumed as a Service
… because then you talk about interfaces, operational qualities and cost to benefit value.
Often times when organizations build internally used software systems, with the goal to reuse it among multiple units, products or groups, there are no contracts in place. Managers and architects see that multiple projects or products build similar components and the idea to centralize them and make then reuseable comes up. Or it is about general SW systems that are used by many parts of the organization like HR tools, CRM and others.
When we focus on re-usable components, we should think of micro-services again. Typical functions that may be reused over multiple projects and products are authentication / authorization, monitoring, logging, billing, metering, diagnostics, integration into internal systems, protocol adapters, … . When organization build such modules and think of re-using them so that they need to be developed only once, often times people forget to define the operations model of those components. My suggestion is, to build teams that own these modules and run them as if external customers could use them, with all the attributes I listed above. The customers may all be internal but that does not prevent you to build a interface contract, to meter the consumption and generate some internal billing (even it it will not include money transfers, you can make it transparent which consumer contributed how much to the cost of the service).
Doing it this way will spark the continous discussion around the value and the cost of the internal services and solution / product teams can decide if they want to use them or not. This is important. In the moment the organization declares that everybody HAS to use the internal services, it will be the end of happiness. The responsibility of the teams that build the internal services is to build a service that has high value and low cost so that it solution / product teams WANT to use it, because they understand that building this part on their own will be more expensive and reduce their ability to build their USPs.
Conclusion
For me it boils down to a simple rule: If you really want to build a sustainable business these days, think about providing your solution as a service. Even when you have only internal customers, build it in a way that you can externalize and monetize the solution any time as a managed service. Yes, it is expensive to build a managed service because you need to solve the multi-tenancy and operational aspects and that will cause ongoing cost to operate and maintain. But when you do not find customer who are willing to pay for this, your cost to value benefits might be bad and your business may not work out. But when you find customers and you can scale, you can really build a sustainable business.