Looking back at years of automation and setting up Environment-as-a-Service with our clients and partners, we’ve made and witnessed quite a few mistakes. I have long wanted to collect some of the lessons we have learned and share them. Blood, sweat, and tears were poured into these, and it’s easy to see the traces of these experiences in how we have shaped our products. Here are my top 5, would love to hear your comments and thoughts!
Keep the end users in the loop
Environment as a service is all about the painful tension between the horribly technical environment orchestration and end users that want it to be dead simple. Infrastructure environments are the base for pretty much every task in a technology company. And today, when EVERY company is a technology company, a larger number of end users couldn’t care less about how complex it is. They want it Netflix-style and rightfully so. When building a service, it’s important to identify the end users and understand their needs, making sure they know how to contact the service admins and who can help them (e.g. “contact us” option). It’s also important to continuously get their feedback. From my experience when a service was launched without involving the end users, no matter how much amazing magic was done in orchestration, it often was rejected and failed (did I mention tears?)
Don’t automate your manual sequence as-is
It’s tempting to approach automation as a series of tasks that are done manually and we need to automate one by one, resulting in a magnificent script that replaces our tedious manual effort. But try to understand your scripts 6 months later or apply some variation and reality hits you in the face.
Automation opens new possibilities. It often requires changing the mindset to achieve maintainability and scalability. Much like test automation, if we try to simply automate what we did manually the results are often sub-optimal. Good automation usually requires some reconstruction of the process – identifying reusable building blocks and finding the right way to model the environment. We’ve been investing in evolving our model for years, and still do (this topic probably deserves its own post!)
Start simple
Automation is such a powerful thing, it is only natural to target the most complex environment, thinking it would be the most valuable to automate, whereas simple ones are not worth it (i.e. “providing developers with a single virtual device is something we do all the time. But come on, it’s one virtual machine, that’s not worth automating”). But the return on investment in automation is highest on things that are easy to automate and maintain AND can be reused very frequently. Some of the most successful implementations I’ve seen started with very simple environments that created an appetite for more
Invest in adoption and visibility
It’s easy to get lost in the joy of technical details and endless automation tasks, but if we spend a year populating inventories and creating building blocks and complex blueprints that nobody uses, it will be hard to convince anyone it’s worth it. It’s important to make sure value is demonstrated in every milestone, that the development of the service is iterative, and that high-level vision is not lost.
A few best practices that would help -
- Start with 1-3 simple blueprints that you think will be used frequently
- Invest in aesthetics – blueprint images, names, meaningful descriptions – make it easy and convenient to consume. Yes, it’s as important as the orchestration part (think shopping in Amazon with the same picture for all products)
- Invest in elements that ease the use and would make self-service easy – attractive user instructions, videos if possible, easy remote access to environment elements
- Make sure you expose your end users to the new service – it’s best if they are involved and contribute. Announce the availability of the service, and actively get feedback
- Track and report your KPIs – present to your management and get feedback
Don’t think automation is magic
Well, automation IS magic for the end users. But behind the scenes, someone needs to make the magic happen, and this is often not a walk in the park. Automation is becoming easier to create, but it’s important to also remember maintenance and scale.
Some best practices on this front -
- Start with offering a few predefined environment blueprints as your service. You’ll get the best results if you maximize reuse. When you let many users create environment blueprints, you’re increasing complexity. This could be the next step, but not recommended to begin with
- Don’t automate things that are not worth automating. I sometimes hear people describe how they are working for months to automate a very complex environment, and then realizing it is used once a year and nobody appreciates the effort. Sometimes people are frustrated with automating very dynamic environments where everything changes on a daily basis – perhaps this is not the right target to start with
- Whatever tool you use to automate, try to use built-in capabilities as much as you can. There are always additional capabilities that may be uniquely required to you and seem
