By now, we should be aware of the benefits that the cloud can bring to any individual or organisation. There are plenty of case studies, talking about the scalable, flexible and economic benefits (See Azure, AWS or Google for more information).
Companies see the cloud as a differentiator and utilise it to disrupt and innovate in their respective markets. Gartner predicts that the total public cloud market is due to increase by 16% in 2016.
But, Chris - You're starting a blog about technology. Why are you talking to me about customer case studies and market fact? Why? Context.
I work with a range of enterprise clients focused on custom development. Custom Development is broad - My specialism is in Azure solution development and DevOps.
Interestingly, there are common themes. Customer X aims to use the cloud to go to market more quickly; Customer Y aims to use the cloud to reduce management overhead. These benefits are very high level, and we need to think a bit deeper regarding achieving those, on a project by project basis.
Consider an e-commerce site. It has users on a 24x7 basis, potentially 365 days a year. It cannot afford downtime, as that has a direct loss of profitability to the business. Potentially millions.
Conversely, consider an internal HR portal for a small business. It is likely used predominantly within working hours and has a limited user-base.
Each of these scenarios will have very different requirements, both from a functional and non-functional perspective. Understanding these differences is important, perhaps even more so when considering the cloud as your next step. You need to think of the whole setup, end to end and not just the architecture. People, Processes AND technology - ITIL anyone?
Thinking solely technical architecture is a very easy trap to fall into when transitioning into the cloud.
Consider the supporting operations. The innovation of cloud technologies is rapid, and keeping up can be tough. But you need to ensure that your processes safeguard you. It is part of the mindset of transitioning from product to service.
It is not just about the cloud architecture, but also about the governance and supporting organisational policies and processes. You will now have a cloud vendor involved. You may be utilising third-party services as well. It is important to ensure there is clarity on responsibilities, clear governance on cloud usage and defined processes and escalation routes for those unwanted eventualities.
You remember what I said about context earlier? There is no "one size fits all". The governance model, operations and architecture are relevant to you, and your solution. That means that you may have a different design to suit an SLA or a different supporting process. Context is important when building in the cloud, so consider this when thinking about your technical architecture and planning your operational procedures and governance.
Over the coming weeks, I will share some of the common risk areas that I have seen in the field. They will, of course, be my personal opinion, though I hope that they will enlighten you. Stay tuned for more.