Recently Kevin Matheny wrote a blog post about how to increase productive time with the Sheriff pattern. I tweeted a reply quickly describing how we handle interrupts at glomex’ SRE squad. We call our Sheriff "Captain Crunch" @glomex_com We even have a hat, a @SlackHQ handle and an Alexa skill so people know who to talk to pic.twitter.com/rXG7My6eji — JohannesBrandstetter (@jobrandstetter) April 11, 2017 I don’t want to dive too deep into the theoretical background on why having a designated person to handle interrupts for a team is a very good thing to do.
glomex is running on a “well architected” AWS setup - as mentioned in a previous post. One of the foundations of this setup is the basic account structure that we chose to build upon. In this post, I want to show you why you would want a multi account setup, how we have actually implemented it, which pitfalls we experienced and what kind of tooling we used. Why we implemented an AWS multi account strategy As for the motivation to go ahead and deal with the complexity of such a setup - there are a lot of good reasons:
Great ideas always start with a draft sketch. To be honest, bad ideas may start with that, too. It may be something you think about or something you doodle on moleskin pages, or even the wireframe you scratch on a napkin with your toothpick. Then these sketches need to be turned alive, and imagine the confusion when you bring that toothpick-pierced napkin to the architect or furniture manufacturer or whoever implements your ideas.
With the glomex Media Exchange Service, the global marketplace for premium video content, up and running, I visited the 10th ACM RecSys conference in Boston to get a hold of what’s new in the world of recommender systems and to be inspired for what we at glomex can do for our users. Here are the top industry lessons learned: 1. Explain recommendations to users There are a lot of different strategies to generate recommendations, be it the most simple one based on overall top lists, or, very sophisticated, based on user-item interaction, user and/or item properties.
To be honest, using anything but Amazon Web Services (AWS) cloud at glomex was never even subject to discussion. glomex engineering and management completely trust AWS to provide us with secure, scalable and innovative services. On conferences such as data2day in Karlsruhe or CeBIT in Hannover, engineers and managers asked me why we were using AWS and how we convinced our management to use it. In this blog post, I’d like to describe our main reasons for using AWS and how we solved existing concerns.
On October 17, 2016 we organized our first official glomex AWS Meetup. As part of the AWS user group in Munich we had invited the Munich Amazon Web Services community to the ProSiebenSat.1 “Besucher-Pavillion“ in Unterföhring. About 75 people travelled to Unterföhring and followed our talks. The event started with beer, snacks and networking. Markus Ostertag from TeamInternet opened the stage presenting the last four weeks’ AWS announcements. Check this webpage to find those latest AWS news and to stay up to date with all the AWS feature releases.
In early 2016, we started moving our new glomex infrastructure to the Amazon Web Services (AWS) cloud and created an amazing product within only six months. To become an AWS SaaS partner, we had to pass an AWS Well Architected review in October 2016. In this review, an AWS solution architect will evaluate if you have chosen a cloud architecture in alignment with the best practices for the use of AWS.