To us, Cloud Operations means a combination of best practices, techniques and processes. Its about taking advantage of all the cloud capabilities while not getting stung. It covers a few broad areas:
- Re-usable deployments to ensure standards compliance.
- Repeatability means better business continuity.
- No click-ops
- Setting and meeting spend targets in the cloud.
- Avoiding the disconnect between consumption and bill paying.
- Reducing out of control cloud spend.
- Using the cloud the way its supposed to be used.
- Getting the most out of it while not being captured.
- Economics, right-sizing and sustainability of design.
Reach out and get in touch with us about Cloud Operations. We’re sure we can help you achieve your goals.
We love to automate stuff
While it might not be getting the love from Microsoft that Github does these days, Azure DevOps is still one of the best integrated platforms for building software, running projects and automating infrastructure builds. As the name might suggest its not just for Azure. There are plugins for several different platforms.
There are lots of ways of defining infrastructure as code. The problem is that not all of them are created equal. Public cloud platforms change quickly and the vendor-provided tools are usually the best ones for the job. Next to that we look for more mature platforms that provide the most flexibility.
jtwo has experience with these infrastructure as code platforms:
Previously based on JSON it now supports YAML which means your sleep isn’t haunted by braces.
This is the native deployment toolkit provided by AWS.
Azure Resource Manager
After Azure Classic, Microsoft went back to the drawing board and had seen CloudFormation. They thought this was pretty good but could do with some improvement.
You can drive this with YAML, JSON or through other tools such as Bicep.
TerraForm is a semi-commercial offering that can do both AWS, Azure and other cloud services. Its also more of a steady state tool that attempts to mutate services to match the configurations you provide. Its a bit like puppet for cloud.
Get in touch with us for help in automating your environments. We’re good at it and there are plenty of rewards from the effort you need to put in.
We hate big cloud bills
We have a service offering called “Frugal as a Service”. We used to call it Stingy as a Service but that seemed a little negative. Frugal is way more acceptable than Stingy. Either way its about ensuring that you only pay what you should for cloud services.
In the 10+ years we’ve been doing cloud there’s a lifecycle that customers go though. Take a look at the timeline on the right and see if its familiar. Reach out and tell us which stage you’re at.
How do we prevent this from happening?
Lets assume you’re at Stage 2 or Stage 3 of the cloud buyer’s journey. The bill is mounting and its all getting a bit white-knuckle stressful.
(We could have used cloudstep.io to prevent just this problem, but now is not the time.)
Public cloud providers get nervous when you’re in these stages. They want you to spend a lot of money with them just not so much that you resent them.
There are a few things to remember to keep this all under control.
- Understand your spend. The first thing is to work through your spend and understand who’s using what and why. Tagging is a great way to do this. You also need to build some dashboards and reports.
- Establish a baseline. Look at what’s steady and what’s increasing.
- Make a hit list of resources. Identify a list of resources that should either be reformed or removed.
- Identify the low hanging fruit. There’s bound to be stuff hanging around in your environment that shouldn’t be there. Add that to the list.
- Run it as a continuous project. You should run a continuous project which keeps adding reform/remove items to the list.
- Bed in better behaviour. Infra and dev teams should be asked to provide 5 year estimates for the projects they run. That way everyone is forced to think about the overall spend.
- Build better architecture patterns. Make cost a component of the sustainability of all new solutions proposed.
Stage 1: Euphoria
First of all, we’re moving to the cloud. Look at all these things that are a few cents an hour or a few cents a gigabyte. We’re going to save a fortune with this stuff.
Stage 2: Realisation
The bill is pretty high, perhaps we should have stayed on-premises. But the IT guys assure me it’ll settle down once we’re all in.
Stage 3: Start yelling and retreat
This bill just keeps climbing month on month. Its going to blow our budget and now we’re in its hard to see a way out. This has been a disaster.
Get in touch if you want help taming your cloud bill. Sometimes it takes a bit of help from outside to get the cost dragon under control.
Good Architecture is more than just a diagram
Good architecture in the cloud has these characteristics:
- Flexibility. If you pick the right technology components and assemble them properly you will be able to adapt when things change and they will.
- Efficiency. Turn the performance knobs up only as far as they need to go and no further. Also pick the right components, there might be several that will suit but some are better tuned for certain use cases.
- Simplicity. Great architecture is elegant and simple. When there are too many components, arrows and boxes on the diagram start to worry.
- Scalability. Good architecture scales from one user to thousands without needing to change. Make sure there aren’t bottlenecks and imagine “what if this thing is as big as Facebook one day?”
- Sustainability. This is a big one and its complex. But it relates to things like available skill sets or how it fits in with other technologies. Does it introduce too many new patterns into the environment?
Public cloud providers offer best practice guidelines for using their services. But they are heavily focused on their services. Most organisations aren’t “all in” with one thing or another and are usually a patchwork of different technology stacks of varying ages. Good architecture for some is not good architecture for others. And remember, sometimes the best practice is simply the way the person who wrote the best practice does it. There’s many ways to skin a cat.
For help with solution and application architecture reach out to us and we can discuss your situation. We’ve got a lot of experience building and operating systems and we aren’t zealots. We like what works.