Caveat: All opinions and predictions are my own!
If you are…
- A storage admin / architect
- A network admin / architect
- A Server admin / architect
- A systems administrator
and…
“I’m not sure where I fit in this new world of DevOps, PaaS, SaaS, serverless, micro services, web apps, containers, IaC, etc.”
or I’m a decision maker…
- Setting business strategy
- Defining IT operating models
- Building new services
- Adapting to changes in the market
and…
“I’m facing some disruption within my business teams / org following a shift in strategy towards innovative public cloud services.”
Then this is the article for you!
Servers are Servers no Matter Where They Are
As I’ve discussed here, a server is still a server regardless of where it is (physical, VMware, Hyper-V, Azure, AWS, etc). It requires pretty much the same skills to architect, deploy, operate and monitor. With the advent of software defined datacentres several years ago, VMware and Hyper-V admins are familiar with virtualised networking. The point I’m trying to illustrate is for our pre-public cloud IT workers and managers a moving servers to public cloud isn’t particularly scary. It’s also not particularly innovative, and doesn’t necessarily solve any long term business problems.
Note: I’ve been in IT for over 20 years and come from a pre-public cloud era.
Translate that into Azure speak and your talking Tenants, Subscriptions, Regions, Management Groups, Policies, Resource Groups, Storage Groups, and VNets in simplistic terms.
New Role – Cloud Architect
Someone(s) to architect / manage / own that over arching fabric and governance is needed. Let’s call this the Cloud Architect. They will plug into Service, Security and Enterprise Architects. The Cloud Architect will be responsible for the landing zone for applications needed by the business. Applications such as an e-commerce website hosted in PaaS, or a File Services system built on servers. The Landing Zone is the core fabric, security and governance where applications are hosted. So the Cloud Architect is responsible for framework within which applications work.
Scaling Architects
Architects are scalable in a number of ways. I’ve illustrated diagrams as examples.
In the hierarchy below you have an owner (Principal Azure Architect) with either direct (line management) or dotted (none line management) to Seniors who in turn are responsible for the design decisions of Azure Architects. This is a silo’d public cloud approach.
It has merits in terms of allowing architects to specialise on a particular cloud rather than diluting their time across multiple clouds.
In the hierarchy below you have a similar setup with Owner/Principal < Senior < Architect. However, these role’s span public cloud.
Advantages here are that you don’t have to cross boundaries in order to solve problems or make decisions. You also don’t have a diverged governance model for public cloud.
You could even split this out further by allowing specialised Architects.
Essential Skills and Experience
Regardless of the particular public cloud, Cloud Architects will need to have the following sound technical skills / experience:
- Networks and networking
- Firewalls and perimeter security
- Backup and DR
- Governance (managing / administering)
- Identity
- Storage
Hands On = Yes
An Architect needs to be able to understand the As-Is as well as the To-Be. I also firmly believe that these kind of roles must be hands on. I work on the basis that you cannot be an expert in something unless you have a feedback loop. I.E. the experience you gain through doing is fed straight back into your designs/improvements. If you’re not doing then your knowledge is all theoretical which exposes a huge risk of whether something you design will actually work or not when put into practice.
So if I’m not a Cloud Architect Where Does That Leave Me?
So where does that leave the system / server / application (on servers) administrators?
Well, orgs will still have servers for some time to come. Those servers will need all the management and governance they need today. Be warned however, I’m coming across more and more businesses that want to be the market leader in the digital workspace for their sector who have come to the realisation that servers won’t help them get there.
Servers are extremely effort intensive to maintain. Unless you have a very streamlined application they don’t scale very well, the patching is risky and complex for server estates, they require a lot of administration to govern and they have a lot of component parts that all need to place nicely.
I’m coming across these companies because as they move to the cloud they don’t want to migrate their servers, they want to eliminate servers where possible. Some companies I work with have achieved this and don’t operate a single server in the cloud.
So in this new world what do we need. Well, a few of things, InfDevs and AppDevs for the Cloud Service design / app modification and DevOps to maintain it.
New Role – InfDevs
This person understands in detail the configuration necessary for hosting a particular application. For example if an application owner is responsible for a web .net application underpinned by IIS and a Microsoft SQL database, and they wish to gain agility by migrating to containers the InfDev is able to have the necessary conversations with the devs, app owner, admins, and your Cloud Architect.
So you may be wondering why xxxDev? This is because this person works in Infrastructure as Code and has a coding first approach to build. As not everything comes preconfigured out of the box, coding is a daily occurrence in the public cloud world. Coding doesn’t automatically = developer. If you’re a server admin in this day and age then you will be familiar with PowerShell or bash and will most likely have put scripts together for making your life easier. Congrats you’re a coder!
Essential Skills / Experience
- Cloud specific PaaS, microservice and serverless architecture
- Surrounding technology
- IaC
- Cloud specific coding languages
- Tools for transformation
New Role – AppDevs
AppDevs go that level deeper and are able to work with developers to understand how their code needs to change in order to be transformed into a new public cloud service. Depending on the scale this could be the same person who is an InfDev.
- Cloud specific PaaS, microservice and serverless architecture
- Coding languages
- IaC
- Tools for transformation
New Role – DevOps
Development Operations or DevOps is a way of working that simplifies and streamlines BAU operations from day to day. The idea being you have devs and ops working together in the same team to onboard application changes following a new release. Unless you are purely talking about an application you develop in-house then you won’t run DevOps in it’s purest form. However, many companies successfully setup and utilise a DevOps team using customised processes to manage BAU changes and support. I’d go as far to say that if you’re not doing this then you should be. I’m not going to go into detail here on how as it’s a rather large subject with many variables depending on your business and they way you want it to work
What would these roles look like in an org. Well, you put them where they are needed but an example is given below:
Essential Skills / Experience
- Cloud specific PaaS, microservice and serverless architecture
- Understanding of CI/CD
- IaC
- DevOps processes and ways or working
- Understanding of SCRUM and/or Agile
- Automation
Considerations for Org Changes
Your business, organisation, department, or team is successful because of the people in it. Upset the people and watch a dip in performance. Sometimes this is unavoidable, but with org changes that are needed to remain relevant or competitive the key part of your strategy has to be communication.
With the move to public Cloud, and in particular away from servers, it’s really important to lay out your plans transparently. Start with why, then move to how. If everyone understands why and then how something is changing it’s easier to make the mental shift. This is particularly important if you are working with a service provider to help you on your journey. You’ve spent a lot of money on them, you don’t want to be wasting it putting them in a room with your staff that don’t understand the “why”. This needs to be a top down supported message and change.
Summary
There is a space for everyone in the public cloud world. It’s a great community of people that love to help each other. However, the technical and non-technical roles are changing so be prepared. As a techy you will have learnt some, most of what you know at home, so start learning something new. There are a multitude of free and cheap online self paced courses. Also look up your closest Azure, AWS, or Google Cloud user group. They are often run by well known experts and are a great way to learn and meet people in the community.
Communicate well. The technical staff are often the engine of your org helping to see it operating, serving customers, or keeping you as market leader.
The Automation Guy 