The car’s list of accessories says “digital climate control.” For one brand, this means that the center of the physical console has a thumb-sized digital display that shows the current indoor temperature. Another uses a large digital display that controls the car’s air conditioning displaying both indoor and outdoor temperature curves rather than a single physical button on the dashboard. And with some brands, you can control the climate automation with your cell phone even before getting into the car.
You can find the same description for the climate control in the manufacturer’s equipment list, but the difference is radical for the driver in real life. This different approach underpins the design thinking and affects the practical implementation and opportunities for the future. The same triangle of thinking, realization, and potential is also present in cloud services. More than 90% of organizations are already in the cloud at some level (451 Research 11/2018). However, the way companies use cloud services vary greatly, and so do the benefits obtained from using cloud services.
I’ve heard many IT managers declare that “A cloud platform was tested, but it was soon discovered that running services in your own data center is cheaper than in the cloud.”
That is true sometimes, and that is where the problem lies. That is, comparing carrots with carrots. And many do compare, not realizing that the radical benefits of public cloud services lie somewhere else. At best, the cloud is like the fresh juicy carrot pie, which you can buy with a cup of fresh coffee if you want to continue the carrot analogy.
But how do you make sure your cloud is not just a plain carrot but a delicious carrot pie? How to Radically Benefit from the Cloud?
Two ingredients play a crucial role in this scenario. Reaction readiness and reaction process. Simple words, but behind them, is a total shift in thinking.
Reaction readiness — the ability to respond to a business need
I divide this ability into two parts: the elasticity in production environments and the capability to support innovation.
By elasticity in production environments, I mean the ability to scale production services according to demand. That is, to keep services running when customers want to use the service. To my dismay, I noticed that still in 2019, during Black Friday, the online services of many merchants collapsed from seven in the morning until eleven o’clock in the evening. Probably one of the year’s best sales days, and the “cash register” could not support the need to scale. Not good.
Public cloud services provide with 100% certainty the scalability and elasticity that e-commerce needs during these busy days, if architected well to support these scenarios.
Building such a service requires a radical change in mindset. The best of the cloud is not harnessed by virtualizing or containerizing servers in your data center and taking them as-is to the cloud. An excellent carrot pie cannot be baked by stacking a bunch of carrots in a pan and putting in them in the oven.
The radically more useful cloud service starts with ingredients produced in a new way and with intelligent cooking instructions. You need to design with cloud and automation in mind.
There are two ways to create solutions and their components in cloud services: serverless and serverfull. The operation and scaling of the Serverless Services is the responsibility of the cloud provider, and they probably have done their job well. That is, serverless services are scaled almost unlimitedly on a global scale. Conversely, if you have a moment when you do not need the serverless service, then it neither consumes resources nor generates costs. There are still some limitations to serverless services at this stage of development, and they may not be suitable for every use case.
Serverfull services are your servers on the cloud platform; you choose the operating system, processor and memory capacity, disks, and other resources and then pay for them continuously and predictably. Services are scaled by clustering services and by allocating additional resources to them as needed. You are responsible for these things, but it is possible to harness automation to maintain these configurations and to scale and copy services between environments with containerization. Indeed, Kubernetes has reached the almost de-facto standard in this field, and Kubernetes is also rapidly moving into service management for several traditional IT product houses, such as VMWare and IBM.
The end result of a cloud transformation should be significantly more performance, and the ability to dynamically allocate costs where they make the biggest difference.
Therefore, you should carefully consider which components of the solution you want to implement with Serverless Services, and in which context it makes more sense to use a more traditional server-based model. You should consider the solutions in terms of usability, performance, and cost.
By capability of supporting innovation, I mean how quickly you can come up with a solution to your new or changed business need. Depending on the industry and the competitive situation, one year behind a competitor may already significantly drive customers to the neighbor’s stall. So speed matters.
Cloud services are not identical in terms of the capabilities they provide to build your services quickly. They do thou provide many similarities. Features such as server-based services, running serverless functions, event streaming, databases, and similar building blocks are pretty much the same in Microsoft Azure, Google Cloud, and Amazon Web Services. Some of the major differences are listed below, even though it is certainly not an exhaustive list:
- Microsoft Azure is a good choice if you need to run a large number of Windows servers and of course, Microsoft has very competitive prices for this. Microsoft may also be the cloud to use when it comes to extending Office and O365 with cloud services.
- Google Cloud offers very economical rates on many occasions. Google Cloud also has impressive capabilities for processing and analyzing large amounts of data, image and video recognition, text interpretation, and anything else you can imagine based on Google’s public services. There are also differences in data center landscapes of the three players. For example, only Google provides a data center locally here in Finland. For many Finnish organizations it is quite important to be able to keep your services and data in Finland if necessary.
- Amazon’s AWS is the most advanced cloud service as a whole. With about two hundred services that AWS has already rolled out, it has the greatest breadth of services available. Of course, a large number of services mean that several different solutions can be chosen for the same purpose, for example, when choosing what serverless database to use. AWS is also by far the most widely used cloud platform in the world, with many integrated solutions, ready-made code and configuration examples, and training offerings. AWS services are “most tried and tested” with the largest user base and thus ready for production with the older services.
In order to be able to serve business quickly and stay competitive, it may not be a smart decision to choose just one cloud and close your eyes from the solutions offered by others. It may be smarter to choose one cloud as a so-called home base but build the ability to leverage the best of each cloud to build solutions.
Better tools are continually coming to the market to support the multi-cloud strategy of managing services across multiple clouds. Likewise, there are more and more hybrid solutions on the market that make it easy for you to choose whether you want to work in the cloud or your own data center. For example, last year, VMWare released its capability to migrate virtualized services between multiple data centers and the cloud. In December 2019, at its re: Invent conference, AWS released Outposts solution that lets you run AWS cloud workloads in your own data center.
The reaction process — the ability to get things done effectively
Even world-class building blocks can’t help if the organization fails. It is best to remain humble and to inspect your thinking with the new possibilities that the cloud services offer, and to consider factors that either slow down or speed up development. Things that used to bring speed and reliability may not bring it anymore. The concept of speed has changed.
While the concept of speed has changed, so has the concept of price.
In the past, ordering new servers could be an investment worth tens or hundreds of thousands, and thus a very rigid process of ordering IT services was justified. In the new world, servers cost a few cents or euros a day and can be switched on or off as soon as you feel it, with immediate cost implications.
In cloud thinking, the distance between potential risks and potential benefits is so short that it is often faster and cheaper to try which direction to go rather than spend time theorizing.
A change in the concept of speed and price leads directly to the need to change the concept of communication as well. The operating environment needs to be radically changed to get the best benefits from cloud computing. You need to be able to build an environment where unnecessary bureaucracy does not slow down or hinder execution.
The first aspect of the reaction process is, therefore, to change the way an organization coordinates and approaches the cloud. These things to change include:
- Contracts about where to target and with what budget. Aim to have clear guidelines on the amount of money available throughout the year and clear business goals for the job. Agree on a set of 4–8 business KPIs, but leave the path to be freely chosen as needed.
- Contracts in place for development resources and personnel. Focus on having the development resources you need. Remain agile, and do not focus your contracts on what outputs they should achieve at what time/cost.
- Establish clear connections to the rest of your organization, especially to your business and IT. Engage representatives of both organizations firmly in your development team and make sure they breathe the same air with the development team every day. You should not waste valuable time with tiring email ping-pong between organizational parts. Business representatives should be able to give their input on a daily or weekly basis as you iterate the service. Likewise, a member of the IT team in the development team personally monitors and ensures that the required network configuration orders and integration work are progressing at the right speed and priority.
Unfortunately, this change means that if things go wrong, you can’t blame anyone outside the team. You are responsible for your success. I bet this increases the dedication of you and your team, and thus your success rate.
Another thing that needs to change in the reaction process is the methods of effective software development. In practice, this often means a change from a customer-supplier model to an organization that builds itself. This change in the way an organization does development is often radical, and many organizations have no previous experience of this.
An organization building solutions needs tools for development, version management, documentation management, requirements management, and backlog management. If you want to build the ability to bring new features to production several times a month, perhaps even on a weekly or daily basis, you’ll need to have clear processes and automation in place. Also, proper test methods and systematic test automation are needed. Automation is needed to release new versions and to manage software versioning. There is a need for automation for new version deployment and probably also versioning and management for interfaces and APIs.
If you want to build the ability to release new features at a high rate, then all the work must begin with building this test and release pipeline. It is only when the automation is running that you should write the first lines of production code to make sure that the deployment process works. Conversely, it may take a long time before you can raise the release rate to once a week or faster. If ever.
And all of these need people to maintain and develop these processes. And discipline. The entire team needs to understand the criticality of these methods to reach success. So make sure that you follow these practices throughout the development process and life-cycle.
Summary
Cloud services offer significantly more to those who are ready to change. To put it simply, we let go of organizing ourselves in an organizational structure and start organizing ourselves around work. Regardless of your job description, organizational unit, or business ID.
Reaction readiness and reaction process.