Continuous Innovation on AWS
The last few years I have been helping a few companies and their teams optimise their AWS Security via Cloud Audits, Improve their Platforms and move from Azure to AWS. Before I make it sound like I'm a super wiz on AWS, all of this happens really well when working collaboratively in teams. What I have enjoyed is watching businesses improve their outcomes significantly. Small incremental changes over time are better in my opinion than large messy change.
There has been a large focus on Continuous Improvement and helping SaaS Founders overcome the noise that is present in the industry. You will always have 1 or 2 vendors providing advice to a customer about how "Things should be done".
And there is always the dynamics of working in a small business or startup that differs completely from working in a large enterprise. In most cases I am battling the status quo and that's the opposite of what SaaS and other Hi-tech startups need.
You can't just expect to deliver the same solution for startups vs enterprises. There are more constraints on time, budget and scope. I guess that's where I come in as an independent consultant and provide some common sense amongst the cloud washing and noise.
Take an example of one customer who was using Kubernetes (or K8s). They were using K8s and after careful consideration around the benefits of using this, it was decided that a more scalable and easier solution for them for now would be to use Amazon ECS. Amazon ECS provides essentially the same outcome but without the added complexity of K8s. They can always switch to K8s later, when they have scaled and if it makes sense.
Or take another example, a customer who has a global media broadcasting reach.
They had a single AWS Account and it was decided that the urgency was to separate their AWS accounts into dev and prod and setup a simplified billing structure for them to be able to report on easily.
So instead of giving the customer a full blown setup, we took it in stages and focussed on a key question "What is the immediate business value we want to get out of this?" When we ask these questions instead of pandering to an automatic "Best Practice" route I typically find that the road map is a lot easier for a company to digest in terms of both time and cost. We can balance best practice with business outcome.
This leads me to another point: Best practice is often used as a stick to shake around, when it should be used as a guiding set of principles to work towards within a team context and the context that fits inside of the particular organisation.
So think about your own technology road map or approach. Do you let consultants and vendors "Do technology to you"? or Do you step back and ensure a technology road map is worked in collaboration with your team, vendors and consultants?