2015 - The year of Micro for web development

This year, I believe more development organizations are finally going to take their New Year's resolution to lose weight seriously.

Microservice architecture

I've seen this general trend at the last three places I've worked, a span of four years, and now is seems that the groundswell is spreading at a rapid pace. Many companies that have built giant, monolothic applications are finally feeling the pinch of decreased product flexibility, painful release cycles, and overly complex codebases. They are taking steps to rip chunks out of one, large ecosystem and build smaller ones for lower maintenance and development costs.

Now, with more software being deployed on cloud services, and those services becoming less expensive and more powerful, development groups can take a serious stab at building services that align with specific product needs, and build lighter products that consume the myriad services as needed.

Unfortunately, it does have a catch.

You need a serious investment in DevOps (I know there's some contention over what that means, but the general consensus supports my usage of it this way). Having more, smaller services requires serious thought into how events and messages will be handled at the infrastructure level. It also increases monitoring, deployment and support strategies.

Here at Lonely Planet, we're undergoing a major overhaul of our strategy for delivering content, and the experience around it, for our customers. Part of that strategy is for the experience to be consistent across all of our properties: destinations, shop, mobile, home page, and travel services. For that to all happen, with minimal total effort when building new products for our travelling customers, we need to define our types of content, and how we want to let customers experience each type.

Once we've defined the core experiences, we can start building those as individual services that our product builders can then compose into public-facing offerings. To offer more flexibility, each services would expose a default experience (styling, components, etc), or just the data if there's a specific product need to redefine the experience.

Content negotiation, usually relegated to API discussions, now becomes part of our content as a service [CaaS] - yes, I coined that term for my discussions about it - infrastructure.

For those who may have some knowledge of the technology behind Lonely Planet, this kind of system architecture is a natural extension of what Ian Feather developed with Rizzo, our live styleguide and component library. Breaking down complicated, duplicated, and complex code into easily consumed, common services that can be shared with any product.

I look forward to writing up a blog post in January 2016 to discuss if we were able to achieve this goal. You never know... it could all go down in flames.

Some good references:

Libraries vs. Frameworks

Another trend that will gain a lot more momentum this year is the adoption of small code libraries that solve very specific problems for building products, and then composing them together. What I call the "Cafeteria Model" for software development.

Large, all-in-all frameworks have been around for a while, but in the front-end world, we've seen players such as Sencha ExtJS, Ember and Angular take on the leadership mantle. Basically, everthing you could possibly need to build web pages, and web apps are included in these frameworks, thus providing a widely adopted ecosystem, and a strong community to support your development efforts. It also provides room for growth. As your products increase in complexity based on what your customers want, you can start to utilize the power of advanced features, even if you're not using them now.

Angular started to really push ahead of the pack in the last couple of years, and tooling, documentation, and extensions were built by the community. Everyone wanted to learn it and it has some powerful features.

Then they said they were going to make the next version Even Better and More Powerful. Awesome, right? Except for the fact that existing implementations would be left, for all intents and purposes, left swinging in the wind with a yet-to-be-defined migration path.

Personally, I never jumped on the bandwagon of any particular framework, because I'm a pragmatist. There is nothing that is one size fits all. Nothing. It all depends on the features of the product, the target customers and their devices, the product's platform, and the existing tools+skills of the development team. I've used ExtJS to build massive, complex, client-side applications, only to, six months later, build another product on just Knockout, Require and Q.

I naturally lean more towards the Cafeteria Model. It allows a team to shift to faster, more productive tools once they appear in the market without having to wait out long release cycles that accompany large frameworks because they have many interests to accomodate. In late 2014, I've heard more and more people start to realize the power of that model, and it's become easier to adopt because more quality libraries exist now. It was much harder to adopt even 3 or 4 years ago.

This year, I believe it will become a major trend as teams now have the resources at their disposal to pick the right tools for the job that do exactly what they need and nothing more.

Many people have been bemoaning the overwhelming churn in JavaScript libraries over the past few years, but I don't. The reason being that I see progress. All the old ideas are new again, but now it's for JavaScript, and as the community continues to be prolific in its production we will see constant improvement. I don't believe that one framework or library should dominate the industry. Then it becomes stagnant, inflexible, and bloated.

Granted, it's evolving at a sickeningly rapid pace right now, but it's needed, and it won't stay at this pace for long. Let's throw 18 solutions at a single problem and let the community marketplace decide who the top couple winners are. It's already starting to happen in a few areas.

These kinds of tools usually do three, or less, things and do them very well. As the front end development and JavaScript development communities continue to mature (remember, this really is a very new field of expertise), it will naturally produce fewer, but higher quality tools as we identify what our real pain points are.

Author

Steve Brownlee