Making (Business) Sense of Microservice Architectures

Every major cloud technology conference these days has multiple presentations about moving to a microservices architecture, so I did some research and tried to answer basic questions like what microservices are, what benefits and costs they provide to businesses, and when it might make sense to think about using them. My findings are summarized below; I think others may find it useful.

1. What Are Microservices?
The Netflix story is a great one for getting a basic understanding of microservices. Back in 2008, the Netflix website was one giant application, also referred to as a monolith in microservices lingo. The Netflix monolith had a lot of problems. For example, a simple error such as a missing semi-colon in the code base could bring down the entire Netflix website for several days. Also, developing new features was pretty slow as code changes (such as adding a new column to a database table) needed cross-functional teams to review and approve. Finally, and maybe most importantly, Netflix needed to move to the cloud so they could scale quickly enough to meet rising customer demand. Forklifting their monolith to the cloud wasn’t really an option, so they spent seven years adopting a Microservice architecture. This meant that they broke down their monolith into smaller, more manageable, and fully decoupled components, exposed through lightweight APIs.

2. Benefits
The benefits of adopting a microservice architecture include:
a. Scaling Efficiently: Teams can easily scale out the application components that need more resources (such as authentication & payments), without having to scale out the entire application.
b. Raising Availability & Fault Tolerance:  The decentralized nature of a microservice architecture eliminates single points of failure and delivers resilient, highly available applications that experience very little outage.
d. Getting Rid of Big Bang Deployments: Application deployment becomes a non-event as teams can deploy their services independently multiple times a day, without having to put the entire application in maintenance mode, or co-ordinate with other teams.
e. Giving Teams Technical Autonomy: Teams can implement their service using whatever technologies they prefer, as long as these services are exposed through standard APIs.

3. Costs
Despite their numerous benefits, microservices come with the following costs:
a. Microservices Imply an Org. Change: At its heart, microservice architectures are about creating the autonomous teams that can build, run and manage independent and loosely coupled services. This usually means a change from the current org. structure, and we all know how painful and emotional org. changes can be.
b. Application Architectures are More Complex: Every microservice architecture is essentially a distributed system, which means that things like monitoring, testing, and end-to-end visibility of the system become really really hard. Also, moving developers between teams becomes more difficult as their new team may work on a completely different stack from their current team.

3. When To Think About Adopting Microservices
According to Martin Fowler, a microservices thought leader, there are a few housekeeping items you need to address before moving your critical applications to a microservice architecture. They include:
a. Rapid Provisioning: You should be able to provision new servers in minutes and not days.
b. Monitoring: You need to know what’s going on within your application; where things are failing and why.
c. Rapid Deployment: Your deployment processes should be automated, and should take minutes and not days.

4. Resources
If you are interested in diving a little deeper into microservices, here are a few resources I found to be super helpful:
a. Blog Post on Why You Can’t Talk About Microservices Without Mentioning Netflix.
b. Video of Microservices Overview by Martin Fowler – Very good overview.
c. Video of Microservices at Netflix Scale: Principles, Tradeoffs, and Lessons Learned by Ruslan Meshenberg (Director of Platform Engineering @ Netflix) – A little more technical depth, but nothing overwhelming. Good presenter.
d. Video of What I Wish I Had Known Before Scaling Uber to 1000 Services by Matt Ranney (Chief Systems Architect @ Uber) – A lot of focus on the people side of microservices.



I Want To Use Data To Improve My Product. Where Do I Start?

Most technology professionals will probably agree that data-driven business and product decisions deliver better outcomes than simply going with your gut, or worse: with the HiPPO. However, an important challenge remains for product teams trying to become data-driven: where do they start?

Below is a series of steps for navigating the path to data-driven product management. These steps could be applied to an entire product, or to a feature existing within a larger product. Also, while it is focused more on technology products, I believe parts of it could be applied outside the technology industry as well. Here goes:

1. Does your product work?: An awesome app that crashes every single time it’s opened is a worthless app. Therefore, the first set of data and metrics to be collected and analyzed should revolve around product health and operational intelligence. This will help you answer questions like how many hours in a day your product is available, what your crash rate is, and what your product’s performance is like during peak times.
Examples of publicly available product health and operational intelligence tools include Splunk and the elastic stack, or ELK.

2. Is it popular?: Once you get going with analyzing your product’s health, the next step is product and user analytics. This means collecting the data and developing the metrics needed to figure out how many people are using your product, and whether that number is trending up, or down. You also want to analyze your user base to identify your product’s user segments, and to begin understanding which segments are valuable, and what the valuable segments care about so you can tailor your product roadmap and marketing programs accordingly. This is not easy stuff, but getting it right pays huge dividends.
Publicly available tools for enabling product and user analytics include Localytics, Mixpanel, and Amplitude.

3. Are product updates changing key metrics?: Every update made to your product that results in no change in any of the metrics that you care about is probably a worthless update. On the other hand, increases or decreases in your business and product metrics may be as a result of external factors such as the weather or U.S elections. 🙂 One way to improve your certainty around what effects your updates are having on your key metrics is by running experiments. In very simple terms, this involves releasing product updates to a subset of your product’s user base, and then comparing the subsequent behavior of the users who  received the update with those who didn’t receive any product updates.
Publicly available tools for enabling experimentation include Optimizely and Unbounce.

4. Is your product Intelligent?: Artificial intelligence (AI) is all the rage today, as it promises to unleash a new wave of tech-enabled productivity on consumers and businesses. However, a critical ingredient for enabling AI scenarios is data. For example, the reason why Amazon can tell you that people who bought item X also bought item Y is because it has huge amounts of transaction data on both items. For your product to be able to support such intelligent scenarios, you need to collect and organize the relevant data sets, and then employ the right algorithms.
The process of enabling AI scenarios within a product usually involves custom development by software engineers. However, publicly available tools that can facilitate this process include Amazon ML and Azure ML.

Image by

A Year in Product Management: What I’ve Learned

A few weeks ago, I celebrated my first year as a product manager. Much to my disappointment, I didn’t get a whole lot of congratulatory messages. Only LinkedIn remembered (thanks LinkedIn!).

Self reflection is something that I truly value, so I decided to take some time to think about what I’ve learned about the product management discipline during the past year. I came up with three key findings:

1. Wearing Multiple Hats is the Name of the Game
Before I became a product manager, my thoughts about the role can be summed up in this beautiful Venn diagram from the pm heels blog:


Now that I have a year’s worth of product management experience, I’ve modified this diagram to become something like this:


2. It is Important to Always be Working on the Most Important Things

From my product management Venn diagram, you can see that there is an infinite number of tasks that a product manager can be involved in. Yes those tasks can have UX, business, or  technology components. However, they can also involve random stuff like getting pizza for engineers who are working late (I haven’t had to do this yet but I happily will).

This brings us to the problem of prioritization. Since no one can do everything, product managers have to constantly check to ensure that whatever they’re working on has a higher chance of improving their product’s success metrics compared to other things that they could be doing. In case you’re wondering, there most definitely are some cases where the most important thing a product manager can do is get pizza for engineers who are working late. 🙂

3. Relationships Matter

I once heard someone describe product management as “the grease and the glue of product development”. It’s up to us to rally our stakeholders around a common goal, and to ensure overall progress towards the achievement of that goal. This means that we have to constantly influence our peers in design, development, and marketing. As none of these people work for us, it really comes down to influencing without authority.

What I’ve learned in the past year (and from folks like Robert Caldini) is that people who like and respect you are more likely to listen to and understand your ideas. In the same vein, you are more likely to listen to and understand the ideas of people that you like and respect. This insight has led me to always try to make relationship investments up front, before they were needed; by then it was usually too late.


Five Agile Practices That Scale

Since the creation of the agile manifesto in 2001, agile practices like extreme programming (XP) and scrum have grown in popularity with startups, but haven’t done so well in large companies. Some argue that the reason for this is that agile methodologies were actually created for small teams in the same physical location, and therefore isn’t as relevant in the highly distributed product development teams that can be found in most large enterprises.

While agile does work best for small, collocated teams, I recently came across a book titled Scaling Software Agility: Best Practices for Large Enterprises, which argued that there are seven agile practices that can be successfully applied across organizations of any size. I thought of sharing all seven, but decided for the sake of brevity to discuss my top five :). They include:

  1. The Define/Build/Test Component Team: Instead of having the database team, the mid-tier team and the web/mobile team come together to deliver a feature, create a feature team made up of database, mid-tier and front-end engineers, as well as other team members (designers, product managers, e.t.c) needed to define, build, test, and deliver value to the customer. Amazon’s “two pizza” teams are a great example of this practice at scale.
  2. Smaller & More Frequent Releases: Move away from the “big bang” release that is done once a year to smaller and more frequent releases. This enables your product teams to respond faster to customer and competitive dynamics. Facebook is a good example of this practice, with its “move fast, break things” mantra.
  3. Concurrent Testing: All code should be tested code. Test cases should be written up before actual coding is done, and checked-in code should be subjected to a barrage of automated tests. Not sure about which big company is a good example here 🙂
  4. Continuous Integration: The product team is not allowed to say coding is done until the code is in a releasable state. This means that it can quickly and easily be deployed to a production-like environment, using a deployment pipeline that subjects it to a series of automated tests. Google seems to have been doing this for a while now.
  5. Regular Reflection and Adaptation: A company that isn’t learning is a company that is dying. Very regularly, product and business teams need to reflect on what’s working and what needs to be improved, and take steps to implement the needed changes. Our fearless CEO is definitely helping us lead this charge at Microsoft! 🙂

These five practices are mostly self evident, and aren’t really a silver bullet. Teams and companies (especially large ones) that adopt them will still face all kinds of challenges as they try to innovate and deliver value to their customers. Notwithstanding, embracing these agile practices will probably lead to faster product development cycles, with less waste (building stuff that no one wants), and empowered teams. Which company doesn’t want that?

Image by


Why Google Gave Android Away for Free: The Business Case for Open Source Software

In 2007, Google unveiled the Android mobile operating system under an open source license. This meant that Original Equipment Manufacturers (OEMs) such as LG, HTC and Dell could access the Android source code, and modify it to suit their specific needs, without paying a penny to Google. Why did Google choose this open source approach, when it could have made a decent chunk of money from selling Android?

While I don’t work for Google, I’ve spent some time researching and thinking about the business case for open source software. I believe that from a business perspective, an open source model might make sense for the following reasons:

  1. Monetization of Proprietary Add-Ons: Open source software is likely to gain market share faster than commercial software as its growth is not restricted by the friction of financial transactions. This rapid growth can then be monetized through the creation of proprietary add-ons. For example, Android now has about 65% market share in the US, and Google monetizes this growth through proprietary apps such as Google Search, Google Maps and the Google Play Store, which power its sprawling advertising business.
  2. Reducing Development Costs: Android’s open source license allows any developer around the globe to improve the Android source code for his/her benefit. These improvements are also available to Google for free, and while Google may not necessarily need the free development effort, it ultimately create a positive feedback loop where Android gets better faster, which leads to more users and growth which Google can then monetize.
  3. Attracting and Retaining Talent: Today’s software developers want to do more than write code that earns them a paycheck; they want to change the world. One way to do this is by contributing to cool open source projects that are used by millions of people around the world. Therefore, a company that releases and contributes to open source software projects is likely to be more attractive to talented developers.


Afropreneurship with Sim Shagaya

I recently came across this video interview of Sim Shagaya. Sim is the CEO of, a fast growing ecommerce startup in Nigeria. The first thing I observed about this guy was his top-notch academic and professional credentials. Sim bagged degrees from George Washington University, Dartmouth College and Havard Business School, then did stints in investment banking (Rand Merchant Bank) and technology (Google) before pursuing his dreams of entrepreneurship within Africa. What I like about the video is that it provides a pretty good insight into the choices he has made so far with respect to starting and growing a technology startup in a developing country like Nigeria. Enjoy!


Kellogg Tech Trek

After completing the roller coaster ride of first quarter exams, the next item on my business school calendar was the technology trek to Seattle and San Francisco. I wrote about this trek in my business school essays, and was actually very excited to be one of the thirty Kellogg students chosen to participate. I understood that the trek in and of itself would not help me get an internship. However, I believe that the knowledge and experiences gained from directly interacting with – and learning about – prospective employers could be valuable during the recruiting process for summer internships.

For those who may be wondering, the trip wasn’t financed by Kellogg. Each student was responsible for his or her transportation, lodging and meals. Our trip was 5 days long, and filled with visits to some of the most admired technology companies in the world today. Our daily agenda looked something like this:

Day 1 (Seattle): Amazon, Microsoft, Expedia

Day 2 (San Francisco): Apple, Cisco, eBay/PayPal

Day 3 (San Francisco): Flextronics, Facebook, Google

Day 4 (San Francisco): Intel, Intuit, Box

Day 5 (San Francisco): Airbnb, Evernote

Other companies which I would have loved to visit were Adobe, LinkedIn, and Workday. Notwithstanding, I thought we had a pretty impressive list. Although it was nice to be physically present at great companies like Facebook, Google and Amazon, the companies that I really enjoyed visiting did one of two things well:

  • They engaged us in very lively discussions about the changes in their industry and how they plan to respond to those changes. The companies that I think did this quite well were Intuit, PayPal, Box and Flextronics.
  • They gave us some sort of insight into next-generation technologies that they might bring to market in the long term. The most impressive company in this regard was Intuit. I also enjoyed visiting the Intel museum and immersing myself in the history of this great technology company. You would think that the companies that would really shine in this regard are big players like Google, Facebook and Apple. However, I’ve come to realize is that the technology industry is so competitive these days that no one wants to ‘show their hand.’ This makes sense, but It was still disappointing to not get to see all the cool stuff being developed at these respective companies.

An unexpected benefit of participating in the technology trek for me was the chance to spend a substantial amount of time with my classmates. We spent a fair amount of time in transit as we moved from one company to another, and this provided me with ample time to meet new classmates and interact with those I already knew on a more personal level. This turned out to be one of my best parts of the entire trek.

I made a slide deck of some of the pictures I took during the trek. I didn’t take as many as I should have so they don’t tell the entire story. Still, as the saying goes, a picture is worth more than a thousand words.