Friday, August 31, 2018

Good talks/podcasts (Aug 2018 II)

Some good talks that I show lately:

Sunday, August 19, 2018

Cloud mindset (tech pill)

To create a significant software system using the cloud we need to think differently than when we are building a system to run in our data center or using VPS from a classic hosting provider.



Outside the Cloud (data centers and VPS),  the underlying computing resources are:

  • Effectively fixed because obtaining new resources requires months.
  • They are scarce because we try to buy the minimum resources needed.
  • Expensive since we have to pay them entirely and amortize them.

But in the Cloud, the underlying computing resources are abundant and fast to provision and this change the rules of the game and deserve a mindset change.



In the Cloud we should:

  • Consider the servers/disks/databases as disposable resources, treated as "just one more". This concept is called Pets vs Cattle and even if I don't like the analogy too much, it is true that it is interesting to read about it: The History of Pets vs Cattle and How to Use the Analogy Properly 
  • Always assume that anything will fail and design for it. The Cloud is based on commodity hardware that is not under our control and allows us to create massive scale systems. Due to the scale, we experience partial failures all the time (machines go down, disks broke, network fail...). As we can not predict at this scale, the best approach is to design for failure and improve the resilience of our system continuously. 
  • Define the infrastructure as code to allow rapid iteration. You can learn more about this concept in this previous blog post  Immutable infrastructure (tech pill).
  • Design to take advance of the elasticity of the Cloud. This includes architect for horizontal scalability so you can scale during peak hours without paying for this capacity during low activity hours.
  • Pay per use and rent not buy. When we design for the Cloud, we should try to use the resources as much as possible and deal with the variability in the load using the elasticity. The mindset should be, rent the most suited resources for the task and release them as soon as possible.





In summary, understanding the Cloud providers APIs and services is only a small part of your journey to the Cloud. The most critical step is to change your mindset and accept new underlying assumptions.

A new engineering challenge 
Construct a highly agile and highly available service from ephemeral and assumed broken components. (Adrian Cockcroft)

Related:

Tuesday, August 07, 2018

Good talks/podcasts (Aug 2018 I)

Some good talks that I show lately:

Monday, August 06, 2018

Honey Badgers, from Team to Tribe

A team is a group of individuals working together to achieve a goal. However, a tribe (in anthropology) is a human social group. That is: a group of people who interact with one another, share similar characteristics and have a collective sense of unity, and identity.

As already explained in several previous blog posts, all the people that worked in the tech/dev department at The Motion formed a cohesive team, called the Honey Badger Team, with shared goals and a common mindset.

The Motion was a typical example of an early stage startup: the platform itself was working well, but we weren't able to reach the product market fit, at least with the initial idea. This led to, the company, the product, and the business pivoting several times in the search for monetization. And although the current model seems to work better than the initial one, the result of all these changes, was that part of the team, including myself, gradually left. Motivation for leaving was different for each engineer, but in my case, I had already fostered a great team and had helped build a scalable platform, and was now looking for a new challenge. And I found that new challenge I was looking for at Nextatil, leading the agile retail revolution, but that is another story for a different blog post.

The important thing was that The Honey Badger Team was no more, and at first, this made me sad. It was one of the cons about changing jobs.
However, (and I'm really not sure about how this happened), we seemed to have created a social group. With our mindset. With our shared history. With our way of working.
And we evolved from being a team to forming a tribe. A tribe with our own communication channels, our jokes, our standard way of solving problems. With a grown/agile mindset, aligned with the XP/DevOps values and practices.

It is incredible, but we are now spread over more than five different startups, and we still all thinking about how to spread our values, our way of thinking, our way of solving problems. Sharing knowledge, sharing values, sharing solutions.
So it's clear that instead of losing a great team, what really happened was I got a tribe instead. :)

Currently, we have two telegram channels, which we use to communicate or to obtain great solutions to any problem that we share.
Moreover, we are thinking about creating our invitational conference: the “Tejones Conf", an event for ourselves, our families and friends of us. If we aren't a tribe, I don’t know what we are.

References

The history of the Honey Badger team:

Blogs from other other Honey Badger tribe members: