How can your internal customers consume your automated Services?
This is an often overlooked part of any automation programme. These days it is fairly easy to implement the latest technology to automate a piece of infrastructure, there is a module out there for everything and implementing it is a case of getting it tested in a lab and deployed to production.
However, just automating your infrastructure is not good enough. To create real value in an organisation internal customers need to be able to quickly, easily and accurately consume that automation.
The old way
Anyone who has worked in a large organisation is familiar with the ticketing systems of making requests to another team.
The concept is fairly simple:
- You fill out a form
- A ticket is created
- The ticket is approved/implemented through various channels.
- Your ticket is completed and your service is ready.
While this works in principle for a lot of services, it starts to fall through in some scenarios:
- what happens if the ticket cannot be implemented?
- normally it is rejected and has to be submitted again.
- How do you modify this service?
- it is another ticket that needs to be tied back to the original request.
- Tickets are sometimes a 'black hole'. As it is difficult to see the progress of the implementation
- Tickets are not designed to be automated.
- most automation here is based on parsing information from a legacy process.
In essence the ticket system has not changed much historically, and in some organisations is the equivalent of sending a letter from one team to another and waiting for a response.
Enter Infrastructure as code
As organisations began to build out the automation of their infrastructure, more and more solutions started to focus on infrastructure as code.
It is a good solution, define all of your infrastructure requirements in code managed by a git repository. Then all you need is a way of syncing that codified definition to what is deployed.
The big repository
As these solutions were implemented, each team within an organisation started to build out their git repositories to define this infrastructure.
What was simple in a laboratory/proof of concept environment then started to become complex.
- A repo works for our team but how do I get my customers to add requests to it?
- The repo is beginning to get too big and slow
- the repo is so large our team is no longer doing the proper checks on it.
Customer cognitive load
Once you start to get your customers modifying your infrastructure as code repo...this starts to become a cognitive load burden on those customer teams.
- Why should the customer team learn how you configure your infrastructure?
- How do those teams get access?
- How can those teams decide what goes in what repo?
- Even if they make a request, if they want to update it in six months they have to go through the whole discovery process again.
The big book of requests
In these ways, the single large infrastructure as code repo per service providing team is like each team having a large request book. Where the customer needs to find the book, go to the correct page, figure out the language and then write in what they want.
This book is then taken back and synched to the infrastructure every night, and the customer just has to assume that this has happened correctly.
If the customer needs to come back to change/update or troubleshoot something later, they are back into trying to figure out the book.
Scale this to 10's of infrastructure teams and the cognitive load becomes very large.
A different approach
Why not give customers their own repo and let them put requests there?
If the repos are placed where the customers want it:
- They can always find where to request services
- They have ownership...because it is part of their teams responsibility
- This ownership creates an accurate, maintained overview of what the customer wants at any one time.
- One setup...gives access to many services.
This sounds great in practice but to implement this you also need an easy, scalable way of detecting changes to this repo and kick off the creating of service based on it.
Create requests then let them get picked up
The analogy of this approach, is that each team would have a whiteboard in their office. They would place sticky notes on the whiteboard with the requests for the services they want.
Every day they would go back to the whiteboard and see whether the sticky notes are moved into the done column.
At any time they could take tickets from the done column, make a modification and put them back onto the board. Or remove them from the board to delete them.
Using NetOrca
NetOrca can allow your enterprise to enable customer git repositories for infrastructure.
It enables this in a simple, scalable and standardised way for more info head to NetOrca