Ways to estimate Enterprise Assessment with Microservice architecture
The most innovative firms are always seeking new ways to gain an edge over the competition. Increasingly, top companies are deriving business value through microservices architecture. This approach breaks down your application into smaller, modular components that align with business capabilities. This allows development work on the application to directly align with functionality prioritized by business value.
Microservices architecture can be thought of as specialized mini-applications that each serve a single business function. They are compartmentalized and self-contained. All domain knowledge necessary for specific tasks resides within a microservice and each microservice has a separate dedicated data store. Communication occurs with other microservices when needed, but they are developed and deployed independently of each other.
Microservices architecture doesn’t necessarily dictate the software development process but lends itself well to an agile approach such as Scrum. Designed for continuous integration and continuous deployment (CI/CD), cross-functional Scrum development teams are a natural fit for building microservices.
Analogy
Let’s compare a traditional, monolithic application to microservices with an analogy of building a model of a house. The goal is to build the model for an imaginary family of five, consisting of three bedrooms, one bath, a kitchen, and a living room.
Approach #1: Monolithic Wood Popsicle Stick House
The wooden popsicle sticks are carefully glued together until the house is complete. The family moves in and it’s exactly as they specified, though a bit crowded when the company comes to visit. As the kids become older, they want their bedrooms. The family must move out during the renovation. To be agile, a room is glued to the side of the house. This solves the addition of a room, but access to the room is through a window, so it’s not acceptable. Again, the family must move out while the longer, but correct, implementation of room addition is architected. The kids grow up and move into their own houses. The rooms are no longer needed, but it doesn’t make sense to remove their rooms because the monolithic house is not easy to change.
Approach #2: Microservices Magic LEGO House
Each room is created as its own independent LEGO structure, a more modular approach. Rooms can be moved around independently without the need to disassemble the house. The house is made with magic LEGOs that allow instant duplication of rooms and removal of rooms as needed. When the company comes to visit, the living room and a few bedrooms can be copied to accommodate the higher demand. Room sharing is no longer a problem. When fewer rooms are needed, they are removed automatically. The microservices house is more modular, scalable, and agile than the monolithic house.
Consider Your Application
A microservices-based approach isn’t a silver bullet and shouldn’t necessarily be the definite choice for your next project. Microservices is a better fit for some projects vs others.
Good Fits for Deriving Business Value Through Microservices Architecture.
The application needs to be scalable. One of the strong points of a microservices architecture is scalability. Each microservice can be scaled independently. If you need more horsepower for a particular function, you can add it to only the microservice that provides that function. With today’s cloud technologies, computing resources can be increased or decreased automatically as demand changes. This makes the infrastructure that supports your application easier to maintain.
Changes to production need to be deployed quickly. Microservices can be developed and deployed independently. This allows your development team to focus on small, high-value features and deploy them quickly without fear of taking down other parts of the application. With a small set of functionalities, microservices are easy to test and are thus more robust.
Application features are highly configurable. Customers have different needs when using the software. It’s common to have configuration built-in to meet their needs without deploying separate applications. Because microservices are designed and separated by functionality, it would be easy to toggle a feature on, allowing you to enable and disable a particular microservice. A microservices architecture, designed correctly, can be highly configurable without the worry of affecting other parts of the application.
The software development process supports CI/CD, your business has an SLA with uptime requirements. If your business does not employ an agile methodology that includes CI/CD, then you would not be taking advantage of the full potential of microservices. It’s a very powerful capability to be able to add a small feature or fix a bug quickly without the hassle of a manual process to deploy those changes into production. Deployment of a microservice does not require taking down the unaffected parts of the application. If your company is new to DevOps or does not have DevOps at all, taking on microservices might be premature.
Technology strategy is aligned with and driven by business capabilities and priorities. Software development priorities are not always in line with business priorities. At times software projects are technology-driven, rather than emerging from a strong business case. Microservices can (and should) be designed around business capabilities and priorities. A good gut-check is to ask yourself if a business needled you to consider microservices, or if the concept of microservices has you on a scavenger hunt for where you can apply it.
Development teams are cross-functional. If your business has an agile software development life cycle, then you probably already have cross-functional teams. This means everyone necessary to complete the work is on the same team, as opposed to being separated by specialty. If you don’t have a cross-functional team, a true microservices architecture might be difficult to achieve. Using cross-functional teams to develop microservices allows work to get done without worrying about dependencies on other teams. Your business can then develop, test, deploy, enhance and fix microservices within one team, resulting in greater business agility.
Programming language and platform independence are important to the business. Microservices can be written in many different program languages. This allows businesses to select the language that best suits their needs and the development team’s skills. With containerization, microservices can be deployed on any platform such as Windows or Linux. A monolithic application, once designed for a platform, must stay on that platform unless redesigned.
The database can benefit from modularity. A benefit of having a microservice that has its data store is that you can change the data schema or even the entire database technology without impacting other microservices. With a monolith, it is much more difficult to change a data store because you have to address all the references to that database or table.
You are in a quickly changing market where you would benefit from quickly testing innovation hypotheses. Knowing the time to market needs for your business is at the core of the agile vs waterfall evaluation. With waterfall, the development process is linear: detailed specifications, followed by design, coding, testing, rework, then deployment. Sometimes different groups are involved in each of the phases of development. This makes it challenging, if not impossible, to benefit from the agility microservices can provide to your software solutions. With agile, cross-functional teams work on the features with the highest business value in short iterations called sprints. With an agile software development cycle, microservices can be developed, fully tested, and deployed in as little as one sprint. This allows your company to be innovative and get necessary market feedback quickly. If a new feature is determined not to be necessary, not a lot of development time has been spent. If the feature is broken, then it can be quickly fixed without impacting the rest of production. If the new feature is valuable, then you can capitalize on the feature immediately.
Need to be able to satisfy growing customer expectations. Customers are not going to wait around for 6 months or more for features they need or for bugs to be fixed, especially in competitive and fast-changing markets. Microservices inherently allow your company to be more agile due to their independent functionality, allowing for your company to grow or change a product to react to the market without costly cross-cutting redesign.
Application future growth needs. Knowing the future of the product, or needing flexibility in the architectural expansion/growth might be a good consideration for a microservices architecture. Emergent architecture may be more easily achieved to accommodate a fast-changing market.
Comments
Post a Comment