Cloud providers (AWS, GCP and Azure) go to great lengths to ensure technical scalability on the cloud. You can create thousands of virtual machines, or globally distribute databases with millions of entries. All of these offerings are tested to ensure they can handle your technical scalability requirements. These technical implications are usually at the forefront of your “to-do” list when converting to the cloud.
One thing not discussed as much is the scalability of your organisation. For example, if your user base grows by tenfold can you administer it as well as you could previously? What happens when you have users on three continents requiring 24x7 support?
When you first make the move to cloud, you may not be aware of this kind of scalability issue looming just around the corner. You probably experience early success with your cloud adoption because of the undoubtedly far-reaching benefits from cloud: Flexibility, mobility and all-around efficiency.
But your small number of cloud consumers has to grow. And when it does, the same tools, same processes and same approach are going to get you into trouble.
When the business starts to grow and become successful, you might think, ‘GREAT’. When really you should be thinking of how to effectively scale business processes so that the business itself can continue growing.
As a rule, the success of an organisation in the cloud tends to be in the form of a hockey stick: the growth is small and sustainable ... at first. Then suddenly it takes off and becomes a logarithmic growth profile. You start with a few users and services. Suddenly there’s a pile-on effect and everyone in the organisation is trying to take advantage of this new technology. What was a sustainable growth rate suddenly becomes a devastating avalanche.
One day you notice it's harder to keep up with user requests than it used to be. Somehow, things just don't get done as quickly. There may be complaints about it.
Consider this a subtle hint.
Your instinct might be to simply add more administrators and hope they can keep ahead of the spiralling requirements. But no matter how many personnel are added, you eventually become stuck in a process bottleneck.
The turnaround time gets longer. The number of people needed to fulfil requirements gets larger. Consistency tends to be a problem. Checklists and procedures will tend to proliferate among the administrators. As hard as people try, no two administrators will create the same thing in the same way. It's at about this stage that mistakes begin to happen.
Your natural reaction here would be to try and combat these mistakes by adding more and more processes, like requiring multiple levels of approval before allowing any change. All this does is contribute to yet more delay.
The result: Total organisational paralysis.
We talked about technology implications, and we talked about process implications. There’s also skills implications.
Your organisation will need to acquire or train a group of cloud experts. This is quite a challenge, as they’re difficult to find and just as difficult to retain.
By continuing to manually service the requests from the user community, you will guarantee a high turnover. The greater the level of expertise in your new collection of administrators, the more likely they are to rebel against repetitious work involving mundane tasks. It’s a catch-22. You need the experts. But the more skilled the expert, the less likely they are to willingly take on repetitious work.
The answer to the business scaling issue is to automate tasks. Use your new collection of cloud administrators, leveraging their expertise to create automation instead of doing things manually.
By working together, business-oriented personnel and the technical experts can document a collection of policies. These policies can be implemented in automation.
Take Kubernetes as an example. If you rely on manual processes, then creating a new cluster is a substantial undertaking. It may require the user to open a new ticket, have that ticket routed to the correct group, then get management approval, then finally someone will manually create the new cluster. A time consuming process.
On the other hand, if Kubernetes cluster creation is automated, then the policies and procedures for standing up a new cluster have already been defined. The user simply requests a new cluster and automation takes care of it. Since the policies involved are all pre-configured, it is no longer necessary to have the manual process.
But you may find that growing your own automation in-house has its own challenges. Administrators aren’t always programmers, so it may not be possible to write what you need. In addition, you will have to maintain what you’ve written which is a long-term commitment.
Appvia offers this functionality off the shelf, saving you the hassle of writing it. We package this philosophy and allow administrators to predefine policies so resources are created with a uniform set of capabilities. This makes resource allocation user-driven instead of process-driven.
Referring back to the Kubernetes example, users can stand up their own cluster without any administrative involvement because all the permissions and policies are already defined. In this way, Appvia can help you realise the promise of scaling your business processes in the cloud.
