Category Archives: Web Services

Bucking the Microservices Fad

In the middle of 2013, I was hired to lead the engineering team at LearnZillion–a digital curriculum for K-12 Math and English subjects composed of videos, slides, documents, and images. At the time, there were several applications in support of the business:

  • 2 Ruby on Rails web applications: the content authoring platform for a select group of users and the content consumption platform most teachers and students used
  • 2 native mobile apps: 1 iOS and 1 Android for students only
  • 1 API inside the content consumption Rails app, which served data to the 2 mobile apps and the web application

After a few months, momentum led us to build a publishing API so that the 2 Rails apps could talk with each other. (Before this second API, we were painstakingly moving data between the two apps via CSV and file exports and imports.)

Having recently left a company where we were migrating from one monolithic application into dozens of microservices, the momentum felt right. It was the in thing to do. Microservices were hot. However, as time moved forward, it became increasingly clear at LearnZillion that a microservices architecture came with a non-negligible overhead cost: the cost of keeping not 1 but 2 Rails apps up-to-date with dependency upgrades, authoring 2 APIs internal APIs, 3 API clients, and often changing all 5 when adding or removing a feature, all to pass data around. On top of the software management overhead, there was the overhead of hosting each and bending over backwards at times to make sure that APIs never called themselves. The benefits of having separated apps and APIs were dragged down by the cost.

We didn’t want the over-complexity and overhead, so over an 18-month period, we did a 180. We brought content authoring into the content consumption app, killing-off 1 Rails app, an API, and an API client. We also transitioned our iOS and Android native apps in favor of a cross-platform Ionic app that WebView-ed our main Rails app on both iOS and Android, killing-off an API and 2 API clients.

We now have 1, hosted app, built the Rails way, that has a median response time of 75ms, 2 hybrid mobile apps that look and function identically, and whenever a feature is deployed to our main web application, it is immediately available inside the mobile apps. No extra moving parts, no coordinated deploys. Most importantly, this setup allows us to scale the impact of each member of the Engineering & Design team by keeping each one focused on the features, not on a microservices architecture.

Bucking the Microservices Fad

Our course, there are plenty of valid reasons to have microservices, purely native mobile apps, etc., but this is not always the case.

I’m merely warning against jumping on the microservices bandwagon because it’s the in-thing. And this is a concrete example of where microservices were hurting a business not helping it. Thankfully, it wasn’t too late to reverse course. And I don’t think our team could be happier with the results.

As one of my colleagues says, “you have to use your brain.”

Amazon Web Services

Tonight I went to a presentation by Jeff Barr, Senior Web Services Evangelist for Amazon, with my friend Patrick. I was interested in learning more about the storage, computing, and queuing services I have been reading and hearing a lot about lately and to check out DCRUG, who hosted the event. (Thanks for the dinner.)

I’ll leave the explanation of the services to Amazon, as they do a fine job doing so. However, I thought I would highlight some of Jeff’s points that may not be inherently apparent or published but are quite interesting and helpful to understand:

Groups often optimistically project and expect their web sites, applications, and services to grow in demand as time goes on. However, if they build a robust infrastructure up front, they typically waste precious time and money on an underutilized system. If they use a shared environment, they imagine a magical transformation from a shared to a dedicated host without considering how they will move their system seamlessly before allowing their creation to cut-off its own revenue stream as it grinds to a halt. Amazon Web Services are built with both robustness and low costs in mind.

Amazon is clearly building a framework, and its licensing agreement makes it clear that they want people building businesses around their services. They’re providing the tools and want to see people build with them.

In addition to a base agreement, each web service has its own sublicense. I like this because it cuts down on legalize and makes this more digestible.

One of the primary goals of the team is to build simple and self-serving services for developers to utilize. They don’t want to throw money at marketing, sales, or support when they don’t have to. This savings in overhead costs equates to cheaper fees for the customers who use their services. They have invested quite a bit of time making their APIs insanely simple and building a positive, self-serving community of developers through the use of blogs, forums, and the like.

SQS is like FIFO but not exactly (it isn’t a trivial problem to solve at such a massive scale).

Amazon doesn’t have as many points of presence as Akamai, so they do not see themselves in the content delivery market. They are still fast, however.

They are hoping to provide a way for vendors to dynamically charge for use of their software inside EC2. One of the audience members pointed out that vendors are currently clueless as to how to appropriately charge in an elastic computing environment.

Overall, I was quite pleased. Jeff did an excellent job evangelizing the services and answered a load of really good questions during and after his presentation. He really knew the services, so it wasn’t just a bunch of high-level garbage.

 I’ve been converted.