Introducing the latest addition to the Technology Services team – The Walkupinator – a device which simplifies the way we log our tickets from people just dropping by.
The Technology Services team at REA Group is extremely proud of the walk up service we provide to our staff, however logging tickets for our walk ups has become problematic.
After a busy morning on the service desk in the Innovation Hub it’s often hard to recall who we’ve assisted or what the issue was. With over 550 people at REA HQ, things get busy. To solve an issue that has consistently plagued our team, I’ve created a system that utilises existing technology to allow users to simply swipe a card to log a ticket. This system, which we’ve named “The Walkupinator” can save the person manning the service desk up to an hour a day, as well as saving time for our internal colleagues – or as we like to think of them, our customers.
In REA, Amazon Web Services (AWS) is our major development and production environment, and CloudFormation (CF) is one of the best tools we’ve found to manage deployments in AWS. At the time of writing, JSON is still the only template format supported by CloudFormation; but if you search for “Programming in JSON” in your favorite search engine, the results may be very disappointing. Some developers find writing JSON templates hard and have trouble with the data format, especially when the templates are big (you can’t have comments, syntactic strictness, etc).
At REA, we encourage people to explore and find new technologies to solve problems, improve product quality and speed up deployment cycles; this freedom to explore has given us a few choices for addressing this problem.
So far in our discussion of Distributed Agile we’ve discussed setting up a distributed team and extreme communications.
Next let’s talk about:
- Enabling teams through technology
- Culture and leadership
As previously discussed we’re pretty keen on micro services at REA. Our delivery teams are organised around small, autonomous “squads” that get to choose pretty much any language and technology stack they wish to implement their solutions.
This inevitably leads to a fairly broad church of language use. 🙂
Previously at REA we’d had very special tools for Load and Performance testing that were quite expensive, very richly featured but completely disconnected from our every day development tools. The main outcome of this was that we ended up with a couple of engineers who were quite good at L & P testing with our enterprise tools while the majority of engineers found the barriers too great. We have moved to an approach which is far more inclusive and utilises many of the tools our engineers are working with on a daily basis. I’ll talk about how we did this for the most recent project I worked on.
So, you’re writing microservices! You’re feeling pretty smug, because microservices are all the rage. All the cool kids are doing it. You’re breaking up your sprawling monoliths into small services that Do One Thing Well. You’re even using consumer driven contract testing to ensure that all your services are compatible.
Then… you discover that your consumer’s requirements have changed, and you need to make a change to your provider. You coordinate the consumer and provider codebases so that the contract tests still pass, and then, because you’re Deploying Early and Often, you release the provider. Immediately, your monitoring system goes red – the production consumer still expects the provider’s old interface. You realise that when you make a change, you need to deploy your consumer and your provider together. You think to yourself, screw this microservices thing, if I have to deploy them together anyway, they may as well go in the one codebase.