How to rapidly develop apps with microservices (part 1)
This is the first in a 6-part series on how to move your team towards the best long-term cloud platform adoption decision.
Since adopting a cloud platform involves a significant commitment, and implies the confirmation that comes from previous work on one or more minimum viable products, the primary goal of this series is to get you to the step of defining an appropriate cloud-based pilot project for your team.
Gartner analysts recently emphasized the importance of doing cloud native development as soon as possible after any initial migration of existing workloads.
Here is a guide to what the series covers:
An overview of microservices (this post), after providing context for business pressures requiring faster app development and delivery, steps through the process a team went through in transforming a specific monolithic application.
Architecting with microservices (part 2) lays out the common capabilities of an architecture for rapidly developing applications based on a microservice. You’ll need these capabilities whether you’re transforming a monolith or developing a cloud native application.
Implementing a microservices application (part 3) provides a method for implementing your own microservices project.
Using microservices development patterns (part 4) presents common development patterns available for implementing microservices applications.
Using microservices operations patterns for resiliency (part 5) presents common operations patterns for achieving resiliency in your microservices applications.
Designing and versioning APIs (part 6) offers best practices for managing the interfaces of microservices in your application.
Mobility and location in user experience
As of late last year, a global majority primarily now accesses the internet through a mobile device.
The business implications of the trend are often brought into focus with cautionary tales about Uber and Airbnb successfully disrupting their respective markets. Incumbents in all markets have been put on notice that their customers will soon be offered increasingly innovative user experiences, shifting expectations. Rapidly innovating the relationship with customers through mobile applications is now a platitude in business planning.
Mobile first is not enough: Your customers for awhile may tolerate a great mobile-friendly version of your existing web site, but you have to ask how long you can keep them waiting for features that augment their mundane lives in context. If implementing your ideas take months—as is often the case with a monolithic application that requires coordinated work among many different teams—your innovation easily could become a me-too offering. A more nimble competitor will always be seeking to grab the baton.
It’s uncomfortably obvious that development teams need to accelerate how they deliver new benefits to users. Since nobody can fully predict user behavior, even the fastest, most successful DevOps program has to be ready to fail in the field of actual user experience. Quickly redesigning, replacing, and augmenting parts of the user experience are a top priority based on analysis of clear usage data.
That’s why a microservices model of developing cloud-based applications is so powerful. It allows a different small team to own the entire cycle (concept, development, deployment, monitoring) for each component of an application, providing the flexibility necessary to precisely iterate an underperforming part of the user experience as reflected by data gathered in monitoring what users themselves are doing. The DevOps process becomes a dynamic interaction–almost a conversation–with users in the field.
Starting from where you are
Failing fast and iterating quickly: these are DevOps requirements for competitive app delivery in the mobile services era. They imply application architectures that decouple services from each other in a continuous development and delivery cycle while ensuring well-performing interactions with users.
While a startup has an advantage in building greenfield cloud-native applications—using a microservices approach along with DevOps tools and practices—incumbent companies often must begin by refactoring an existing monolith.
Let’s look at a specific example.
In this case, an online retailer wanted to transform a monolith into microservices in order to learn more about customers, and to quickly update and introduce new features.
Since browsing the online catalog presented pressing business problems to solve, the transformation of the overall app began there:
Pilot Task: Determine and implement a better handling of the catalog
The current app failed to help customers easily find product data and blocked the business from exposing data to other sites.
As a proof of concept for the microservices approach, the team built a single microservice for the business catalog using the following steps:
Establish a new continuous integration/continuation development model to do the work.
Import data into an elastic search to get new ways to search their data and identify new data.
Link the existing website to the new search.
At this point, the catalog was still integrated with the existing ordering components, which run core business logic and were too complex to break up without additional work. However, with a successful pilot, the team was convinced of the value of microservices and decided to expand the scope of the app transformation.
Task 2: Learn more about the customer
To learn more about the customer, the team created an account microservice by figuring how to shift the business to focus on customers instead of inventory.
When they determined that customer experience could be enriched over time based on analytics, marketing, and cognitive data, the choice to use an unstructured database became obvious. So they designed a new customer model and used a NOSQL database (like Mongo DB or Cloudant) to manage the unstructured data.
Task 3: Innovate the user experience
The team built a new native mobile app and created a new front end for mobile and web access. Even though the catalog depends on the legacy ordering code, the overall user experience was noticeably enh
Task 4: Update access to the order microservice
The team created new order APIs for mobile and integrated them into existing transactions. The business decided to create an adapter microservice that called into the existing ordering system of record on premises. They also used the adapter to integrate with new payment methods and systems.
Task Next: Create an new auction feature
Within the newly flexible architecture, the team has planned to add this innovation in upcoming sprints.
Asking the right questions
As you think about the example, consider these questions:
What do your customers want–now and next?
Are users of mobile devices satisfied with the experiences your apps are providing?
In terms of delivering what users want, how are the DevOps processes and practices of your IT organization helping and hindering?
Considering what’s hindering your Devops, and assuming you have an existing app monolith that you need to modernize, do you know exactly what you need to do first?
What experiments with cloud platforms should the individual members of your application development team be conducting?
What is a good pilot project to use in evaluating a microservices approach and cloud platforms for implementing it?
The next post will go deeper into architecting an application within a microservices model.
What to do from here:
Read the next post in the series–on architecting a microservices application.
For developing a cloud native (‘greenfield’) application, view an interactive architecture diagram of a microservices online store application and access a tutorial on deploying the same app in a Kubernetes cluster.
For selecting a secure cloud platform, read this guide.
Roland Barcia (IBM Distinguished Engineer/CTO) and Kyle Brown (IBM Distinguished Engineer/CTO) collaborated with Rick on this post.