Increasingly, more and more businesses are opting for a “Cloud First” IT strategy. Cloud can offer huge benefits from different dimensions such as reduced operational cost or accelerated development. What often gets overlooked is that a single cloud may not give you all (or any) of the perceived benefits for an application that is the wrong fit for the services that cloud can offer.
At the simplest level, there are multiple classes of services that can be consumed from a CSP (Cloud Service Provider).
Some of these provide access to Software (SaaS). These are specific software services that provide a very particular set of Capabilities. Examples are wide ranging, but common examples are ITSMS Software like ServiceNow, Enterprise Planning systems like Workday and Office and Collaboration such as Microsoft 365. You could argue that some of these could also be classed as Platforms.
Others provide Platform (PaaS) Services — for example a Database or Container Platform. These are capabilities that can be used to build systemsThese vary hugely in terms of quality, maturity, breadth and sometimes importantly, lock-in.
The last main category is Infrastructure (IaaS). This category is almost commodity now, but there are still important differences that should be carefully evaluated before selecting the CSP. Examples could include Virtual Machines, Firewalls and Loadbalancers.
Too often we see customers selecting a CSP based on high level commercials, a sales pitch or worse still a golf course conversation. The reality is that there is no single right answer. Where one CSP excels, another may be weak.
To combat this, some of our customers have a slightly better and common approach of splitting workloads across Clouds:
- Adopt SaaS wherever a quality product meets the majority of your requirements (80:20 rule).
- Traditional workloads (IaaS) — use Azure, AWS or another strong IaaS provider.
- In-house developed applications — use AWS and their very strong suite of PaaS.
- Big Data, ML and AI — Google Cloud Platform (GCP) is a common choice.
- Workloads that need to be portable across Clouds or to spread operational risk — Kubernetes (a complex topic we’ll cover soon) on any of the big 3 Clouds.
- Office Applications, Identity and Endpoint Management — Azure and Office365
Whilst this is better than a single Cloud strategy, it is still not ideal and in many cases the ROI post migration may be significantly more than expected and almost certainly more than the optimal pattern.
What does good look like?
The ideal approach is to analyse each application, workload or idea; put together a target architecture and THEN look to fit the architecture to the capabilities CSPs can offer. There will likely be multiple candidates at this point.
Next weigh up the cost of using those CSPs and enabling the target architecture. The complexity of doing this will depend on the risk appetite and Cloud maturity of the business (for example, is the ideal provider already on boarded, guardrails in place and patterns for usage built?) as well as the Capabilities on offer.
At this point it’s really important to weigh up skills. A well architected Cloud has common patterns and ways-of-working across different CSPs and architectures, but all are a significant change from traditional ‘on premise’ architecture and patterns.
There are also huge differences in approach across Clouds. Particularly at the IaaS and PaaS layers. An expert in Azure is not necessarily an expert on AWS. Each have their own nuances and gotchas. A common Infrastructure-as-Code language (like Terraform) might help here, but there is no substitution for experience.
The target architectures and approaches can be categorised into a few common patterns:
Consuming an Application
As part of your requirements evaluation you found a SaaS provider that meets most of your requirements. Great! What’s next?
Integration. How are you going to integrate things as simple as access, authentication, authorisation and audit? All of these are critical to a successful, compliant external application. Do you currently use VPNs? SaaS is generally not particularly compatible with that approach.
You need to re-think what you trust. It’s not the network anymore.. it’s the user and hopefully the endpoint as well. This is a step change that most of the organisations we come across have not yet broached. This means they are in limbo between a traditional network-centric approach and a modern, borderless design. Do your Cyber Teams understand the new world? The approach is vastly different and new skills are needed. Sometimes this ends up with traditional security constructs overlaid onto a modern architecture. Nobody wins in this situation.
Building an App
Hopefully the business has evaluated SaaS before reaching the conclusion that they need to build their own application. Often, building an application is both the most complex option, but also the one with the most reward — assuming what you are building is unique (if not, maybe you should buy rather than build). How many of the major Digital corporations in the world today have bought their app off the shelf? None. But how many of those have also built their own ERP or CRM platforms? Very few (unless that is one of their offerings). It’s worth remembering that. Spend your effort on building value, consume the commodity.
Ok, so my application is pretty unique, I want to invest.. what’s next?
If you’ve reached this stage, the most efficient way to build your application is often to consume as many Platform Services as possible. This reduces the overhead of setting up services yourself; significantly reducing the up-front costs and time-to-value.
Whether this is the right answer long term really depends on scale and skill. If you have the capability to build and maintain a similar service as well as the scale (and spend) to make this worthwhile, transitioning to IaaS, or even a Private Cloud and building your platform services on top may be beneficial. This evaluation is critical.. tying your application into a proprietary PaaS service may make re-architecture difficult.
Balance this with the features you need. For example, if you need a message bus with no fancy features, maybe consider one that is AMPQ compatible, but realise that the proprietary versions often have extra features or integrations that can reduce the time to market of other parts of the application. The right answer might be to take a direction for the first few years and then review. This would be much easier if you plan for that review at the start. Make sure the data or transport layers in your application are abstracted. The last thing you want when your new application is successful is to tear it up and start again! Equally, realise you probably are not Google. Build your infrastructure and applications in a scale appropriate way. Not by compromising on the ability to scale but by delegating the complexity and engineering effort.
If the business is used to managing static, persistent server infrastructure in a traditional private “cloud” (it is often not very cloud-like), the move and transformation to can be huge. If teams have not approached concepts such as CI/CD (Continuous Integration / Continuous Deployment), Infrastructure-as-Code, Idempotency, microservices and modern observability; mistakes WILL be made as part of the learning process. These can be very costly to recover from — possibly more expensive than the wrong application architecture. Consider if you have the right skills at the start.
What Cloud should I use?
This should always come down to the detail of the application (if done in the most efficient way).
Want a new, Zero-Trust Directory Service that integrates with your Windows Desktop estate (if you are adopting SaaS, you probably want this)? — you might want to look at Azure Active Directory (VERY different to Active Directory from other CSPs!)
Building a mobile app? You might want to look at GCP’s Firebase.
Building a API to offer B2B or B2C Services.. AWS API Gateway, Lambda and their associated PaaS is very robust and powerful.
You’re building a mobile app that uses an API layer (more than likely)? Maybe use both GCP and AWS. Particularly if you have on boarded both at the organisational level already.
Hosting an Application
Hosting an application is still by far the most common pattern and I expect that to be the case for the foreseeable future.
For commercial applications, specialised workloads or open source software, this is often the only realistic approach. PaaS often doesn’t work out for technical or commercial reasons. However; if you are writing a new application and deploying it on IaaS — you are very likely missing huge benefits! I’ve seen that pattern adopted by so many large organisations — digging deeper, it is almost always because it’s just what they have always done and they don’t realise there are better, more efficient approaches now. Make sure you understand all your options before finalising your architecture.
Even once IaaS is determined as the right approach, there are numerous areas where the project can take a wrong turn.
Modern approaches should be adopted wherever possible. An anti-pattern I see frequently we call ClickOps (thanks Costas) — where an admin is clicking around in a GUI to deploy systems or configuration. This should be avoided at all costs. How can you be sure that the same clicks are done for environment A vs environment B (or Dev/UAT/Prod)? You can’t. What if you need to quickly re- deploy? Very difficult and mistakes are made under pressure.
Adopt Infrastructure-as-Code principals — ensure what you are doing is defined in code and therefore repeatable. Some CSPs support this way of working better than others. In AWS for example, IaC is promoted as the primary approach. In Azure it is secondary. This fundamentally affects the maturity of the APIs that are needed. Make sure you consider API stability and maturity.
Some good rules to go by:
Never allow long-running servers — or “Pets”/“Snowflakes”. These types of systems always have configuration drift, leading to inconsistencies between environments and worse, nodes within the same environment. Don’t look after systems as Pets, manage them like cattle. Some of them die, don’t fix, replace. Automatically.
Block interactive logins — for the same reasons. Manual changes or deployments are not consistent.
Continuously deploy and ensure your methodology supports idempotency .
Conclusion
Cloud is hard, but the benefits can be huge. A top-down approach is the right way to select products; and it’s the right way to select a Cloud Service Provider. Start with your requirements and target architecture and build out a plan from there.
At Airwalk Reply we are experts in Cloud and modern application architectures. We can help accelerate the complex groundwork needed; including:
- Migration Assessments — will you improve your TCO with a move or re-architecture?
- Well Architected Reviews — have you, or can you make the most of the Cloud?
- Landing Zone Design and Deployment — enabling a Cloud Service Provider for robust usage
- Application Architecture — helping to leverage a mixture of Cloud Services and good software architecture
- Development and Engineering Teams — getting it done with specialist resource