Last month I wrote a new post, namely: Building a simple, resilient, cheap network service with AWS. Now that AWS’ billing cycle for November is complete we can ask ourselves how cheap was that “cheap” in the article, and give an answer. The cost is not exact to the cent, due to the presence of a a stopped instance I am keeping around, but will still be good enough.
To summarise, the article described how to set up a service on spot instances, thus saving on the EC2 cost. We want to understand if we really saved money, and if there are opportunities to save even more. If you haven’t read the previous post, it’s probably a good time to do it now. If you did, let’s go and check the bill.
In this post I’ll describe how I put together a number of pieces of information about AWS features to experiment with an idea. It’s nothing advanced, rather: it’s what happens when you are studying on something and you start seeing the possibilities. Don’t expect rocket science then, it’s more like a handful of notes I made in the hope they may be useful to more people than just myself.
Being an experiment where I was supposed to learn how to do things, it’s a manual set-up. Automation will follow, and in my case , it will be Terraform, but not in this post.
In the last few months I have been working, together with a colleague, on an API client for several well-known systems and cloud providers. When we started, I was a novice in the Go programming language, I had no experience in programming API clients, and I trusted the makers of the APIs enough to have great expectations at them.
Today, a few months later, several hours programming later and a bunch of lines of code later, I am a better novice Go programmer, I have some experience in interfacing with APIs, and my level of trust in the API makers is well beneath my feet.
This article will be a not-so-short summary of the reasons why we started this journey and all the unexpected bad surprises we got along the way. Unfortunately, I will be able to show only snippets of the code we have written because I didn’t get the authorisation to make it public. I will make the effort to ensure that the snippets are good enough to help you get a better understanding of the topics.
OK, enough preface. It’s time to tell the story.
Days ago I came across an article from the series “The long read” of The Guardian. The article, titled “Crash: how computers are setting us up for disaster” analyzes the downsides of overly reliance on computer-controlled systems and automation in general. It’s an incredibly well written essay and I wanted to contribute my own two cents to the topic.
This is not an article about how you can work with JSON in Go: you can easily learn that from the articles and web pages in the bibliography. Rather, this post is about the concepts that you must understand clearly before you set yourself for the task. Don’t sweat, it’s just two concepts two, and I’ve tried to explain them here.
In the last few weeks I have worked together with a colleague to write some automation with Golang and the Atlassian Crowd API. With several separate user databases (and, at the current state, no hope to unify them in a smart way) it would be very handy to take advantage of the APIs offered by, say, G Suite to fetch all the email addresses related to a user and use that information to automatically deactivate that user from all systems.
Coming from a Perl 5 background, I was hoping that decoding and encoding JSON in Go was as simple as it is in Perl. But it turns out that it wasn’t, and it’s obvious if you think about it: as Perl 5 is weakly typed, decoding any typed data into an “agnostic” data structure must be simple. Encoding a weakly typed data structure into a typed format may be a bit trickier, but as long as you don’t have too many fancy data (i.e., in this context: strings made of only digits or non-obvious boolean representations) this will also work well. But with strongly typed Go and struct field names having side effects depending on upper-/lowercase, that’s a different story.
As it often happens in cases like this, you will not find all the information you need in a single place. This is my attempt to collect it all and hand it to you, so that you won’t have to waste as much time as I did. You will still have to read through stuff though.
In my quest to learn the Go language I am currently in the process of doing the Go Code Clinic. It’s taking me quite some time because instead of going through the solutions proposed in the course I try to implement a solution by myself; only when I have no idea whatsoever about how to proceed I peep into the solution to get some insight, and then work independently on my solution again.
This is written to my older self, and to all those using Mozilla Thunderbird and the Lightning Calendar add-on with Google calendars and they see this:
If you are seeing this, the solution is to change the setting
calendar.google.enableEmailInvitations to true:
and everything should work as expected:
I have attended the Config Management Camp in Gent this year, where I also presented the talk “Promise theory: from configuration management to team leadership“. A thrilling experience, considering that I was talking about promise theory at the same conference and in the same track where Mark Burgess, the inventor of promise theory, was holding one of the keynotes!
The quality of the conference was as good as always, but my experience at the conference was completely different from the past. Last time I attended, in 2016, I was actively using CFEngine and that shaped in both the talks I attended and the people that I hanged on with the most. This year I was coming from a different work environment and a different job: I jumped a lot through the different tracks and devrooms, and talked with many people with a very different experience than mine. And that was truly enriching. I’ll focus on one experience in particular, that led me to see what the future of configuration management could be.
2017 has been a pretty good year for this blog.
The 10000 mark was passed for both the views (13790) and the visitors (11454); the previous records were established in 2015 for the views (10395) and in 2016 for the visitors (7520).
The top three visiting countries are the US (3251), Germany (1037) and France (763). My own country, Italy, didn’t make the top 10 with only 328 views.
The top three articles of the year were An init system in a Docker container with 3287 views, followed by Dates from UNIX timestamps in OpenOffice/LibreOffice (3123) and Exploring Docker overlay networks (published this year) with 1601 views.
2017 was also an year of change. In November 2016 I have left Opera Software and joined Telenor Digital as Head of IT. I have more “managerial” tasks now, less time for “operations” and the scale is definitely different than the one I was managing in Opera. That had an impact on the contents I was able to post in this blog, both in terms of topics and amount. Whether the new course is better or worse, only time will tell.
Can Promise Theory help you shape a better, effective leadership style?
Promise-based leadership will be the topic of the talk I will hold at two conferences. The first one is the Config Management Camp in Gent, Belgium, and it’s pretty close: February 5th. The second conference is the glorious Incontro DevOps Italia 2018, the Italian DevOps Meeting in Bologna, on March 9th.
When I joined Telenor Digital as the Head of IT I had to find an unconventional leadership style, as circumstances didn’t allow for a traditional one based on the “line-of-command” approach. After so many years spent with using CFEngine it was quite natural to me to use Promise Theory to model my new “reality” and understand how I could exploit exactly those peculiarities that were making the traditional leadership approach pointless.
Promise-based leadership has clear limits in applicability. It requires the right attitude in leaders and the right culture in the company. Where the right leaders and the right culture are present, I am confident that it provides significant advantages compared to the conventional approach based on top-down imposition.
I have been doing promise-based leadership for a bit more than one year now, regardless of people being direct reports or simply colleagues at any level of the hierarchy. My talk is a report of the experience so far. I don’t have definitive answers yet and there are several unanswered questions. I will be a bit tight with my talk schedule and I won’t be able to take many questions, but I hope to have several interesting conversations “on the side” of the conference events 🙂
One fun fact for closing: when I submitted to Config Management Camp I wasn’t really confident that my talk would be accepted because, I thought, the topic was kind-of “tangent” to the conference’s, so I didn’t even plan to attend. Later on the keynotes were announced, and one of them will be held by Mark Burgess, the inventor of Promise Theory. A few weeks more and I was informed that my talk was accepted and they actually liked it. So I will be talking of promise-based leadership at the same conference, in the same track and in the same room as the inventor of Promise Theory himself. Guess how hard I am working to put together a decent talk in time… 😀