Capstone Seminar in Digital Enterprise , Ph.D. Teaching...

51 Brattle St. Cambridge, Mass.

p. 617-555-1212 f. 617-555-2121

[email protected] www.ideacentral.com/ITeam

Capstone Seminar in Digital Enterprise Instructor: Zoya Kinstler, Ph.D. Teaching Fellow: Takayuki Ida, MBA, ALM, MSPPM, MS

MICROSERVICES @ FREEDOM MUTUAL, INC. Conversion to Microservices Architecture in support of “Growth by Acquisition” Business Strategy

Team 2: Dave Waltz, Rabindar Subbian, Scott Pullen, Kelley Kage, Jim Goodspeed

TEAM 2: DAVE WALTZ, RABINDAR SUBBIAN, SCOTT PULLEN, KELLEY KAGE, JIM GOODSPEED

MICROSERVICES AT FREEDOM MUTUAL INSURANCE, INC.

FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE B

TABLE OF CONTENTS EXECUTIVE SUMMARY .............................................................................................................................................. 1

Part 1. BUSINESS REQUIREMENTS ......................................................................................................................... 3

1.1. Business context ...................................................................................................................................................... 3

1.2. Required functionality ............................................................................................................................................ 6

1.3. Business benefit justification ................................................................................................................................. 6

1.4. Financial Cost & Benefit Justification ................................................................................................................. 7

Part 2. TECHNICAL SPECIFICATION AND PROTOTYPE .............................................................................. 9

2.1. Architectural approach ........................................................................................................................................... 9

2.2. Architectural Details ............................................................................................................................................... 9

2.3. Software Solution .................................................................................................................................................. 15

2.4. Integration with other Applications and Data Sources ................................................................................... 16

2.5. Data Design and Management ............................................................................................................................ 18

2.6. Solution demonstration ........................................................................................................................................ 19

Part 3. IMPLEMENTATION PLAN .......................................................................................................................... 21

3.1. Solution Delivery Roadmap ................................................................................................................................ 21

3.2. Operationalization ................................................................................................................................................ 24

3.3 User Enablement ................................................................................................................................................... 26

3.4. Success Metrics ...................................................................................................................................................... 27

APPENDICES .................................................................................................................................................................... i

Appendix A: ELK Stack ................................................................................................................................................. i

Appendix B: Microservice Diagram ............................................................................................................................ ii

Appendix C: Support Tools & Event Management ................................................................................................. ii

Appendix D: Tool Costs ............................................................................................................................................... v

Appendix E: Implementation Timelines .................................................................................................................... v

Appendix F: Seven Keys ............................................................................................................................................. vii

Appendix G: “Quote” Function Sequence ............................................................................................................. viii

REFERENCES ................................................................................................................................................................. ix



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE 1

EXECUTIVE SUMMARY We are the ‘IT Innovation Team’ at Idea Central, a global technology strategy consulting firm specializing in Technology Strategy and Domain Driven Design. Idea Central is headquartered in Cambridge, Mass. with offices around the world. The team is composed of Dave Waltz, Rabindar Subbian, Scott Pullen, Kelley Kage and Jim Goodspeed.

Our client is Freedom Mutual Insurance, Inc. – a Top 5 auto and property & casualty (homeowner’s, renter’s) insurance firm in the US with about $40 billion in annual revenues. writing auto, property and casualty insurance policies. Freedom Mutual has adopted a business strategy of growth by acquisition. They are acquiring whole companies and the books of business of other companies retrenching from the auto, property and casualty insurance space.

FREEDOM MUTUAL’S BUSINESS AND TECHNOLOGY PROBLEM As Freedom Mutual expands, there is an urgent need for faster, flexible, and inexpensive methods to migrate quoting applications and customer data from acquired companies. The cost of expansion, scalability, performance, application enhancements, and ongoing maintenance of the application and infrastructure have been rapidly increasing. This proposal is to improve the performance of the application as the user base and functionality increase, while reducing future expansion and maintenance costs by moving existing web services to a microservices architecture.

Currently Freedom Mutual’s policy sales and management applications are architected in a Service Oriented Architecture (SOA) consisting of an enterprise service level, which sits on top of the database layer, that serve Freedom Insurance’s web and mobile apps. The current services are large, with many interdependencies requiring elaborate governance and extensive regression testing for any change. This presents difficulties in delivering software enhancements and functionality in a timely and agile manner. This also makes it difficult to migrate new acquisitions into the same framework without huge expense.

In the next five years, usage of Freedom Mutual applications is expected to more than double making it critical for Freedom Mutual’s IT organization to be able to scale and deploy new enhancements and new applications in a rapid and continuous manner. To retain market leadership Freedom Mutual must re-architect its current services platform to be able to quickly respond to an ever changing market.

Idea Central is recommending that Freedom Mutual start the microservice conversion with a small Proof Of Concept (POC) in the Auto Quote service space. This POC will entail splitting the existing Auto Quote Business Service into smaller microservices consisting of Driver History, Vehicle Type, Driver Info, Zip, Customer and Quote. As we are recommending a side-by-side implementation, the existing Auto Quote service will not be modified, allowing us to make changes to dependent applications one at a time. We are proposing, as part of the POC, changes to the Agent Portal front end application be made




to utilize the new Auto Quote microservices. This has the benefit of not impacting our consumer customers which has a much larger user base. As the benefits of the microservices architecture become evident remaining services such as Property Quote, Rating and Bind can be converted to the new platform.

SOLUTION AND RATIONALE The solution being proposed by the Idea Central team will improve application performance, improve code management/deployment and make it possible to deliver features and acquisition changes faster for Freedom Mutual Insurance. Moving Freedom Mutual’s current Service Oriented Architecture (each service could be described as a monolith) to a microservice based architecture will provide many benefits. The main driver of leveraging microservices is isolation. Services provide separation of concerns within the application, doing one thing and one thing well. Due to isolation, a microservice architecture achieves robustness, scalability, agility, and reuse. Services can be tailored appropriately based on their characteristics such as data needs, CPU load, memory usage, and network usage providing robustness.

Development teams can choose the right language or tools for the job based on these characteristics. As each service is isolated, if any one service fails, it minimizes the impact on the rest of the application and provides further robustness and a more predictable experience for the end user. Deployment impacts and timelines are reduced as the deployments focus on individual services instead of the entire application. Scalability is achieved via isolation because each service can scale up and down based on the performance characteristics of the service. Scaling individual services is more cost efficient than scaling larger monolithic applications. Development teams are also more flexible as the code base is smaller, making it is easier to bring on new team members as the code is easier to understand. Microservices also allow teams to become more agile. Teams are able to add new features faster either to an existing service or add new services. They are able to provide better test coverage, which are generally quicker to run reducing the feedback loop that a developer would incur on larger monolithic applications. The microservices approach to architecture is helping companies become more flexible and responsive to shifting customer demands. Microservices Architecture is a valuable complement or replacement of traditional Service Oriented Architecture (SOA) methods when speed and flexibility are important such as with web-facing and mobile applications.1

KEY PERFORMANCE INDICATORS

• Reduced time to integrate acquired company’s IT infrastructure due to microservices architecture. • Improved response times during times of heavy load. • Improved code delivery and deployment processes. • Reduced costs and downtime for maintenance, as each service is separated from the others. • High availability and process resilience improvements in disaster recovery with expected 99.99%

uptime.

The team at Idea Central believe that implementing a Microservices architecture will provide a strong base for innovation, flexibility and scalability that will support Freedom Insurance’s future growth while at the same time reducing operating costs and aligning with business objectives.




PART 1. BUSINESS REQUIREMENTS

1.1. BUSINESS CONTEXT We are the ‘IT Innovation Team’ from the global technology strategy consulting firm Idea Central, headquartered in Cambridge, Mass. with offices around the world. The team is composed of Dave Waltz, Rabindar Subbian, Scott Pullen, Kelley Kage and Jim Goodspeed. Our client is Freedom Mutual Insurance, Inc. – a

Top 5 auto and property & casualty (homeowner’s, renter’s) insurance firm in the US with about $40 billion in annual revenues.

1.1.A. FREEDOM MUTUAL BUSINESS STRATEGY Freedom Mutual’s current business strategy is to “grow by acquisition”. New acquisitions can be an entire insurance company (e.g., Citizen’s Insurance, Inc.), or its subsidiary operating in a regional market (e.g., Citizen’s Insurance of Massachusetts, Inc.), or a “book of business”, i.e., an existing set of auto and property & casualty policies owned by another insurance company that is willing to sell it. Such sales occur for a variety of reasons like mergers or acquisitions of smaller firms by larger multi-line insurance firms (i.e., lines in addition to auto insurance) where the auto insurance business is a small part of the business and is sold off. E.g., MetLife Insurance acquires a smaller multi-line insurance company and sells the acquired company’s auto insurance “book of business” while retaining / merging the life insurance business into MetLife. Opportunities to acquire companies also arises when existing auto insurance companies are forced to exit regional markets due to their particular business conditions. E.g., Citizen’s Insurance, Inc. exiting the state of Massachusetts and other New England states as part of a broader company strategy to focus on Mid-West and South where it has substantial market share.

1.1.B. ACQUISITION BUSINESS REQUIREMENTS With each business acquisition there is significant business and servicing logic from the acquired company or “book of business” that needs to be incorporated into Freedom Mutual’s information technology systems. This is in addition to the data associated with the insurance policies themselves. Thus acquisitions involve 3 high level business requirements:

• INCORPORATE the policies acquired;

• MAINTAIN the policies for the duration of the policy term; and

• COMPLY with the terms of the policies as written at the time of policy issuance.

When a “book of business” or whole company is bought by Freedom Mutual, the policies acquired have to be incorporated into Freedom Mutual’s policy servicing system under the same business terms as when the policy was issued. This involves having to maintain large parts of the acquired company’s information technology (IT) functionality that helped service the policy for as long as the policy is in effect and/or moving the policies into Freedom Mutual’s information technology systems. This is the INCORPORATE requirement. It can potentially result in substantial amounts of changes to the business rules and functions supported by Freedom Mutual’s IT systems.




A key fact to note is that most auto, homeowner’s and renter’s insurance have terms ranging from 6 to 12 months. When a policy of an acquired company comes up for renewal, Freedom Mutual, depending on the terms and business circumstances of the acquisition, either has to maintain the policy under a separate brand (e.g., Citizen’s Insurance brand) or issue the policy holder a new Freedom Mutual policy under the same conditions as the policy that expired (though potentially for an alternative rate). This is the MAINTAIN requirement.

In addition to these complexities of merger/acquisition, auto insurance is a highly regulated business with the regulation determined at the state level. So, Freedom Mutual has to COMPLY by the terms of insurance of both their policyholders and that of the acquired companies or books of business.

There are a few “core” Business Services needed to operate Freedom Mutual, Inc. and for the purposes of this assignment we have decided to simplify them as follows.

• “Quote” – to quote policies to new customers.

• “Policy” or “Bind” – to convert a quote into a legally compliant and binding insurance policy

• “Policy Management” – to manage / maintain policies while they are in effect

• “Claims” – to handle claims arising from the policies underwritten by the company

There are several “ancillary” Business Services that provide information to the core business services or influence their business processes and rules. E.g., “Ratings” applies information derived from other systems/sources that influence the ratings (driver history, claim history, vehicle etc.), “Property” which might handle information about properties etc. that is often needed to quote a policy that involves multi-line (i.e., auto and homeowners’) policies for the same primary insured.

Each of the Business Services needs several Enterprise Systems that apply the business rules to the actual data about policies and insured individuals, their driving histories, vehicle histories and so on. Each business service may call upon one or more enterprise system multiple times during a single business FUNCTION like issuing a quote for a new or renewal policy. E.g., Policy system to find a type of policy to issue, Customer system to find information on a particular insured, Rating to find information on the types of business rules to apply to find the rate to quote, DriverRecord system to find information on driving history of the covered individuals, Affinity to find business rules for discounts due to the customer being a member of an organization like AAA or Harvard University employee etc.

When a new business or “book” is acquired, additional business services may be needed like new types of riders (i.e., exceptions or additional coverages such as limited flood coverage) that the acquired company’s policies contain but are not a part of current Freedom Mutual’s core or ancillary business services. There could also be changes to current business rules as a result of acquisition – e.g., new discounts for being part of organization etc. that are not currently a part of Freedom Mutual’s affinity programs or new features like the ability to convert a policy written by the acquired company to a Freedom Mutual policy under the same terms etc. but branded under the original company’s “brand”.

Each of the changes to the Business Services above could result in changes to the Enterprise Systems Layer as different sets of information is gathered or different business rules are applied for the same FUNCTIONS




(e.g., issuing a quote) that are part of Freedom Mutual’s business functions. Illustration of a small BUSINESS SERVICES change “Expanded Glass Coverage” that policies of an acquired company “A” offers in Massachusetts but which Freedom Mutual does not currently offer. There are changes to the “Quote” Business Service and addition of expanded glass coverage business rules. A new business services feature – “expanded glass” is needed with new business rules for new and renewal policies of the policies from acquired company “A” which have been INCORPORATED into Freedom Mutual but have to be MAINTAINED as company “A” branded policy in order to COMPLY with state of Massachusetts insurance administration rules.

These changes result in a new ENTERPRISE SYSTEM “Expanded Glass” having to be created with corresponding changes to existing “Glass Ratings” functions in “Ratings” enterprise system and business rules of “Discount” enterprise system.

Current / ‘AS-IS’ process

It is important to focus on the business context and establish functional requirements for the proposed enterprise system. What will change in the business operations with the proposed system's implementation? Let’s start with reviewing a system change in the as-is model for Freedom Mutual. As shown in Figure 1 below, to make a change within the Quote Service, every box that is marked in orange was impacted in some way (analysis, coding, or testing) to get the change implemented. In the SOA architecture each service is very large, and completes multiple functions, i.e., full regression tests are needed of all areas to make sure the change in code did not break another piece of functionality. The data in that master database must be verified as well, since all downstream systems rely on the data, so there are data validations needs as well to make sure the code change did not impact the format of the data being stored.

Figure 1: Freedom Mutual’s Current SOA Architecture illustrated by insurance “Quote” function




Important items to highlight are that each Client service has different functions but must make multiple calls into the SOA Services to get the data it needs. If we follow the path of the desktop client (blue arrows in Figure 1), one sees that it makes an initial call to the Quote Service. That Quote Service then must call into the Rate service, and must pass through each Enterprise service to complete the transaction. Each service is comprised of up to 200 pieces of functionality being executed with each call. This impacts performance, and causes large impacts when a change needs to be made, and requires extensive analysis and design, as well as regression testing to make sure no negative impacts are encountered. This also leads to a large number of interdependencies, and means that even small changes can trigger large regression testing efforts. A change like the one described normally takes 2-4 weeks, with full day deployments required to get the code built and deployed to each environment.

1.2. REQUIRED FUNCTIONALITY The requirements for Freedom Mutual are that they would like this project to achieve the following goals:

• Deliver system changes faster, with higher quality, and less user impacts.

• Reduce the timelines required for average company acquisitions to be completed.

• Reduce maintenance expenses while still maintaining business critical levels for application performance and scalability.

• Leverage security, authorization, and authentication protocols that are already in place.

• Reduce as much duplicate code as possible.

• Allow services to work with any client that calls into them.

1.3. BUSINESS BENEFIT JUSTIFICATION Moving the current monolithic system to a microservice based architecture provides benefits for both the business and the IT department. The core benefit of the microservice based approach is treating business functions in isolation. The isolation provided by a microservice based architecture allows for a scalable system, robust system, allows teams to become more agile, and provides better reuse of system components.

Scalability provided by the microservice based architecture is achieved from the DevOps changes that need to be made to the infrastructure to support the architecture. With a monolithic system, if the application starts to receive more load than it can handle, it will scale horizontally. This is a wasteful utilization of system resources, as it is usually a small subsystem or small group of subsystems that warrant the need to scale.

With a microservice based approach, services are scaled out appropriately under performance characteristics that can be tailored to the service itself. The performance characteristics can include CPU, memory, network usage, or time-based when spikes are known to occur. This can provide a cost savings, only using resources when needed. Scalability also occurs on the developer management level. Since the code bases are generally smaller and treated in isolation, they are generally easier to understand and get up to speed on.

Robustness of the system is another benefit of the shift in DevOps needed to support microservices. The system is more resilient to failure and downtime. If an instance of a service goes down, mechanisms are in place to self-recover and replace the new instance quickly, similar to how the infrastructure handles scalability.




Thus impact on the entire system is minimized, since if one service fails the rest of the system can continue to function (albeit with potentially reduced functionality), reducing both downtime and perceived downtime.

This is beneficial to the business as downtime can prevent users from doing what they need to do and cause the enterprise to lose revenue. Downtime of the system also impacts other areas of the business; such as calls to help support agents. Microservices are generally lighter weight vis-à-vis SOA/monolithic applications and can be containerized with tools such as Docker to facilitate easier and quicker to rollout of new deployments. This reduces the deployment time and minimizes any downtime that might result compared to deployments in larger monolithic applications.

Robustness is also achieved by giving development teams the ability to choose the right tool for the job. Monolithic applications are often reduced to the lowest common denominator in terms of technology. Microservices frees developers from this constraint and allows them to choose programming languages, data layer (RDBMS vs NoSQL), caching strategy, etc. based on the characteristics of how the service will be used.

Isolation allows development teams to improve agility because they can integrate new features quicker, such as merging business logic to support acquisitions, and deploy to production reduced interference with other services that make up the system. Being able to deliver features to market quickly will help Freedom Mutual maintain its competitive advantage. Given that services are generally smaller code bases revolving around a business function they are easier to understand. This allows teams to know exactly where and what to change when new feature requests are needed for a given business function.

The size of the code base also allows for better code coverage producing higher code quality. Given that the code base is smaller, the test suite is also smaller, providing quicker test execution, shortening the feedback loop that developers can use while developing and maintaining the service. The development teams also implement and maintain application containers (such as Docker), providing complete control over the system process. Finally, microservices provide higher reuse of functionality by being composable. Services can reuse the functionality of existing services which can lead to cost reductions of future products.

1.4. FINANCIAL COST & BENEFIT JUSTIFICATION The financial benefits from this project will be delivered in two phases. The first is the relatively short term scope of the project of about one year. This part of the plan is to act as a proof of concept by moving just one piece, “Auto Quotes” (from the business services) and moving to a microservices architecture. The ROI for this comes from the reduction in process time to roll out new features or functionality to a process, such as “quotations”. In the current structure, an update to quotations would require approximately two weeks to fully regression test each piece that is involved. With the new microservices infrastructure, this time is cut down to a single day. This is a 90% reduction in time for regression testing. Monitoring this time reduction will be critical, not only to ensure everything is moving smoothly but to keep the following new features/implementations on schedule.

The long term part of this project is when all of the processes have been migrated to the microservices structure. This will allow the migration of acquired companies to be fully integrated much quicker. Currently, an acquisition takes approximately two full years with a team of 200 development engineers working on it. By moving to microservices, this time is expected time is expected to be reduced to six to nine months. This




labor reduction, and retirement of legacy systems being able to happen faster (reducing maintenance needs) results in savings in the millions, and would free those engineers up quicker to allow for additional acquisitions to be processed as well.

Currently, there is an offshore deployment team that handles regression testing and implementation. After the migration to the microservices architecture, that team will not be needed as their function will be migrated to the DevOps team that is internally supporting each of the microservices.

The cost to implement this project will be based primarily on development costs. It is expected for the first set of microservices to take nine months to implement. The overall project will need to take approximately five years to fully build out the microservices architecture completely. A team of 20 developers working on this at $50 per hour would be approximately $2 million.2 Over the course of five years, that would result $10.4 million. By comparison, the savings with the first acquisition, post new architecture, would be about $26 million.




PART 2. TECHNICAL SPECIFICATION AND PROTOTYPE

2.1. ARCHITECTURAL APPROACH In a typical Service Oriented Architecture (SOA) environment, the services are large and coarse grained. In the case of Freedom Mutual, two examples of the existing SOA services are Auto Quote and Property Quote. Contained within these large services are several business processes such as capturing customer information, obtaining vehicle information and gathering driver information. In a SOA environment, a change to the driver information code would impact all of the other parts of the Auto Quote service. Getting this code to Production would also require a full deployment of the service even though there may have been no changes to the customer or vehicle areas of the service.

A microservices architecture solves this by splitting and grouping the services by discrete business processes, or contexts. Each context becomes its own independent, autonomous microservice that can be deployed and maintained separately from other microservices. Changes become easier and less risky when a modification to one microservice is independent from the other microservices.3 Microservices also introduces the concept of composability where the APIs of the microservices can be used by different consumers, both internal and external, for different use cases because they are generic enough to be used by multiple applications. An example of this might be allowing a third party to use a Quote service to sell insurance on Freedom Mutual’s behalf, opening up new business opportunities.4 A microservices architecture will make Freedom Mutual more flexible and adaptable to new business acquisitions as well as open up new distribution channels.

To support the microservices migration, Idea Central will make certain that legacy client applications and current SOA services continue to interoperate with the new microservices and rewritten applications to ensure current federated application requirements are met. The microservices architecture is a proven strategy that will make Freedom Mutual’s suite of Policy Management Applications more flexible, scalable and robust.5

2.2. ARCHITECTURAL DETAILS A high level diagram of the Proof of Concept (POC) system architecture can be seen in “Figure 2: Microservices Architecture during POC and migration”.

At the top level are Client-Facing Applications, or the consumers of the microservices. These consumers will call into the microservices that they require via public RESTful APIs managed by WS02 API Management Layer, an open source API manager. This API manager will broker the public-facing APIs to the consumer applications, including third party applications. WS02 enables API discovery and self-service while also providing important features such as role-based access and security of managed APIs.6 In addition to the features WS02 offers, it is an open source solution and an industry leader in the API management field.




Figure 2: Microservices Architecture during POC and migration

In the Microservices Layer, individual microservices will be built in such a way that each microservice will have a small independent database that will have all the data it needs to service a request. An example of this would be the Quote microservice - all of the data for this service will be stored within a MongoDB database, removing the need to call back to the master database. The MongoDB database was chosen for the Quoting microservice, as well as the Customer, Zip and Driver microservices, due to the flexibility that it offers. As the data is unstructured with no schema, bringing on a new acquisition's application which may have different business requirements and fields should be easier. The MongoDB database also has good support for Consistency, where all database nodes will have the same data, and Partition tolerance where disruptions in communication between different database nodes is well supported.7 Idea Central plans on hosting the microservices on multiple servers for redundancy so partition tolerance is a critical feature to our architecture design.

The databases for the different microservices could be a NoSQL database, like MongoDB, or a relational database depending on the requirements of that particular microservice, just as the individual microservices could be written in different languages as need dictates. As an example, while a MongoDB solution makes sense for the Quoting microservice, the Vehicle microservice will use a PostgreSQL relational database because the vehicle data stored within it is structured and generally static. As the data will be exposed through WS02 APIs, the data storage for each microservice can be different as dictated by need.

Any intercommunication that the microservices require will occur via the RabbitMQ Event Management Layer, an open source messaging bus which provides support for multiple languages and protocols, including the Advanced Messaging Queuing Protocol (AMQP). This messaging bus will provide a highly available message queue, flexible routing and extensibility through a large number of plugins.8 RabbitMQ follows the




model of a dumb pipe with smart endpoints – all business logic is contained within the microservices, not the message queue itself. As with WS02, RabbitMQ was chosen due to its strong feature set in addition to its position as an industry leader in the messaging queue space. While each microservice and its associated database is a self-contained unit there will be a high degree of communication between the microservices and the front end applications, all occurring through RabbitMQ. To illustrate the data flow and communication an example of a quote flow is shown below.

Note: A detailed sequence diagram of the process is provided in Appendix G.

1. Enter Zip: Customer enters their zip code into a front end application, e.g., customer accessible website with web application to manage their policies.

2. Broker Zip Data: The zip data is brokered by WS02 API Management Layer and is handed off to the Zip microservice.

3. The Zip microservice runs the calcProductsOffered method to check if insurance is available at that zip code.

4. Push Event: The calcProductsOffered event is pushed to the Event Store via RabbitMQ Event Management Layer.

5. Broker Response: A response is given from the Zip microservice back to WS02 and then the front end application.

6. Enter Customer Data: If insurance is available the customer will proceed to enter their personal information such as name, address SSN, etc. The city and state information will be pre-populated from a lookup in the Zip microservice.

7. Broker Customer Data: This customer data information will be given to WS02 to pass to the Customer microservice.

8. Store Customer Data: Customer microservice which will store the new customer information in the local microservice database with a unique identifier for the customer record (CustomerID).

9. Push Event/Pass Quote Data: At this time a unique QuoteID is also generated to uniquely identify the quote. This QuoteID and the CustomerID are sent to the Quote microservice via RabbitMQ. The new customer data creation event and the quote record creation event will be pushed to the Event Store via RabbitMQ.

10. Create Quote Record: to create a new quote record in the Quote microservice database. 11. Broker Response: A response is given from the Quote microservice back to WS02 and then the

front end application. 12. Enter VIN: The customer will proceed to the next screen in the front end application and enter the

vehicle information for the automobile they wish to insure. 13. Broker Vehicle Data: The customer entered VIN data is passed to WS02 which then hands it off to

the Vehicle microservice. 14. Vehicle Lookup: The Vehicle microservice does a lookup on the VIN and returns back the safety

features of that vehicle to send to the Quote microservice. 15. Push Event / Pass Vehicle Data: The vehicle lookup event is pushed to the Event Store via

RabbitMQ.




16. Update Quote Record: The unique identifier of the vehicle from the Vehicle’s microservice database gets added to the quote record in the Quote microservice database. The vehicle information is pushed to the Quote microservice via RabbitMQ.

17. Broker Response: The response is sent back to the front end application via WS02 API Management Layer for the customer to verify.

18. Enter Driver: The customer will proceed to the next screen to enter in additional drivers to be insured. The customer enters the information for all drivers including driving history, employment status, etc.

19. Broker Driver Data: This driver data is passed to the Driver microservice via WS02. 20. Store Driver Info: Driver microservice stores the new driver information in the local microservice

database. 21. Push Event / Pass Driver Data: The driver events are pushed to the Event Store via RabbitMQ. 22. Update Quote Record: The driver information from the Driver microservice database gets added

to the quote record in the Quote microservice database. The driver information is pushed to the Quote microservice via RabbitMQ.

23. Broker Response: The response is sent back to the front end application via WS02 API Management Layer for the customer to verify.

24. Enter Affinity: Finally, the customer enters any associations and affinities they may have that could provide a discount (e.g. member of the alumni association of a particular university).

25. Broker Affinity Data: The affinity data is sent to the Quote microservice via WS02. The Quote microservice calculates and generates the Auto quote based on the information provided by the customer.

26. Update Quote Record: The affinity information gets added to the quote record in the Quote microservice database.

27. Push Event: The affinity information is pushed to the Quote microservice via RabbitMQ. 28. Broker Response: The quote is returned to the front end application via WS02. 29. Return Quote: This is the “Quote” that is presented to the customer. 30. Data Sync: All new data generated from this transaction is replicated to the legacy Master Database

through the Data Pump and Data Gateway.

A critical part of the architecture (“Data Gateway”) will keep the data in sync between the legacy master database and the individual microservice databases. After the migration has been completed, the data pump process, outlined in section 2.4 will ensure the availability of data to all downstream applications.9 Due to the event driven nature of the microservices architecture, a local database, typically a MongoDB database will store all events (the Event Store) that the microservices create. MongoDB, an open source NoSQL document database, is a logical choice for the event store as the events themselves will be JSON documents.10 These events are immutable and will provide a snapshot of the application state at any point in time providing valuable auditing information that does not exist in the current SOA environment.

Idea Central will be using Docker containerization to manage a service’s environment. Docker provides a portable environment that can run on premise or later be moved into a cloud infrastructure. 11 Initially all services will be run on premise due to security and regulatory requirements that Freedom Mutual needs to comply with. Further, we will be implementing a Kubernetes cluster using existing hardware that Freedom




Mutual already has. Kubernetes is open-source system for automating deployment, operations, and scaling of containerized applications12 such as Docker images. In the Kubernetes system, a template is created defining the characteristics of the containerized service such as memory, networking with other services inside the cluster and external to the cluster, and number of instances. Kubernetes orchestrates the deployment using a rolling deployment strategy and spreads the processes across the cluster, making efficient use of the hardware. During the deployment, if a failure does a occur, the rolling deployment will be rolled back to the previously good working application image. Kubernetes can also scale the application appropriately depending on the scaling policies.

The applications that use the existing SOA services will need to be modified to take advantage of the new microservices. Freedom Mutual has recently rewritten its client applications to utilize a responsive design and as part of those rewrites the applications were updated to clearly separate business logic and UI elements into a Model, View, Controller (MVC) framework. While the service layers of these applications will need to be rewritten to utilize the new microservice APIs, the impact will be lessened due to the fact that UI elements were separated from business logic minimizing the areas of the applications that will need to be modified.

Idea Central will start the POC with the current SOA Auto Quote service and separate it into a number of microservices that will operate parallel to the existing legacy SOA Auto Quote service. The existing SOA Auto Quote service will not be modified so that applications that consume this legacy service can be migrated over one at a time and not be impacted. The Auto Quote service was chosen because there are many business processes with clear boundaries that can be easily decomposed into microservices. The following microservices will be created based on the functionality in the current SOA Auto Quote service. The attributes of each microservice are listed in the tables below.

Customer microservice get/setFirstName get/setLlastName set/getStreetAddress set/getCity get/setState get/setZip get/setBirthDate get/setSSN Functions:

● Verifying address ● Verifying social security number with government agency ● Credit History

Vehicle microservice getVIN getBodyType getModelName getMakeName hasCruiseControl hasAdaptiveHeadlights hasAirbags hasAntilockBreaks hasDaytimeLights hasStabilityControl hasAlarm getYear Functions:

● VIN verification ● Auto safety feature lookup

Zip microservice getCity getState getZone getDefaultAddress calcProductsOffered getAnnualPrecip getElevation get/setPrimaryLocation




Functions ● Get and set location information ● Calculate the insurance products available in this location

Driver microservice hasDriverCourse get/setEmploymentStatus get/setGender get/setEducationLevel get/setMaritalStatus get/setYearsLicensed get/setNumberAccidents get/setLastAccidentDate Functions

● Get and set information about all drivers Quote microservice calcAffinities get/setEffectiveDate gen/get/setQuoteID hasMultiPolicy

calcDiscountAmt genQuoteAmt getPrefill get/setAutoPurchaseDate

Functions:

● Based on the driver history, vehicle history, and location determines a quote for a customer.

● Prefill customer and vehicle data.

An important aspect in implementing a successful microservice architecture is to establish robust monitoring.

Because the current system is monolithic, it is easier to trace information through the log files and monitor

the health of each server. With the introduction of microservices, each of which will run on its own server,

Freedom Mutual will now need to monitor many services and be able to trace the calls between them in order

to debug any problems. The microservices will be running on their own hardware, in a virtual machine, or

running in the cloud, meaning there will now be more resources that need to be monitored for status. The

solution to this is to implement the Elasticsearch, Logstash, Kibana (ELK) software stack and supporting

plugins, which will be utilized to provide log aggregation, metric aggregation, and performance monitoring

(Appendix A). Servers will run Filebeat and Topbeat, which push service logs and system metrics to Logstash

to be stored in Elasticsearch. Figure 3 below shows the progression to microservices alongside existing SOA

services.

MICROSERVICES MIGRATION STEPS 1. Migrate existing modules into their own packages within the existing code base by their seams, or

code that can be treated in isolation.13 a. For the Freedom Mutual microservice POC, this will create Customer, Vehicle, Driver, Zip

and Quote modules organizing them into clear bounded contexts. 2. Break foreign key dependencies in the database between bound contexts. 3. For each module, define service objects to act as gateways to retrieve data from other microservices. 4. Create calls to modules to retrieve associated data through the service/gateway objects. 5. Create a new database for the microservice. 6. Create the microservice for the module. 7. Migrate data from existing database structures into the new database backed by the microservice. 8. Update service/gateway objects to retrieve data over RabbitMQ to the new microservice.




9. Delete module from the monolithic quoting application after all clients/consumers have been migrated to the new microservice.

2.3. SOFTWARE SOLUTION While microservice-based architectures provide the flexibility to utilize an array of different programming languages, the first microservices to be developed will be built using Java and the Java framework Spring Boot. Freedom Mutual is already heavily invested in Java and JVM technologies, so utilizing known technologies will make transitioning to a microservice-based architecture smoother.

The Spring Boot framework is aimed at developer productivity by bringing together the elements of the Spring framework and using a convention over configuration approach. Gradle, a build scripting framework, will be used to manage library dependencies, test runner, and provide a build process for services built with Spring Boot. The TestNG framework will be used to unit test the services. The internal structure of a typical microservice in the Freedom Mutual environment can be seen in Appendix B.

Inter-service communication will be handled with the RabbitMQ message broker. RabbitMQ uses AMQP, which will transfer messages using JSON. Client services will generate a correlation id on the message payload in order for events to be tracked throughout the whole system. RabbitMQ will be utilized for both event-driven and request/response based communication. The microservices will create consumers which are backed by a queue, bound to a routing key for specific messages. When messages are placed onto the queue, the consumer then pulls the message off the queue and processes it.

If a service goes down, RabbitMQ provides resiliency by providing durable queues where messages can continue to be queued and processed once the service comes back up. It also provides a maximum number of retries for failed messages which can be used to prevent degradation to any services. Requests initiated from a

Figure 3: Progress to microservices alongside existing SOA services




client will set a timeout to prevent performance deterioration in the system in case downstream services are not functioning properly. The full request/response communication can be seen in Appendix C.

Services that provide data for front end applications (websites, mobile) and external applications will communicate using REST over HTTP utilizing the WS02 API manager. Public API data will be represented using JSON or XML formats depending on what the consumer requests.

2.4. INTEGRATION WITH OTHER APPLICATIONS AND DATA SOURCES There are three main groupings of integrations that need to be analyzed to support the new microservices POC for Freedom Mutual: microservice to microservice, Auto Quote service to Downstream Systems, and Acquisitions being integrated with Freedom Mutual’s Auto Quote service. All three integration types will make the microservices discoverable, easy to use for consumers, and will remove the need for services to understand the internal implementation details of each microservice, while supporting simplified acquisitions.

MICROSERVICE TO MICROSERVICE INTEGRATIONS The first integration is microservice to microservice. By utilizing RabbitMQ as described above, it is possible to use a combination of synchronous (request/response) and asynchronous (event driven) integration strategies based on the best fit for the particular microservice. RabbitMQ will broker the communication between the different microservices and front end applications using JSON which is technology agnostic. This is a critical component of the design to ensure that Freedom Mutual does not get locked into a particular technology stack, and allows for easy integration between microservices.14

An example of an asynchronous call would be a request for pre-filled data on the Policy Information screen that needs to be returned from a vendor, and will be used to populate data on the vehicle screen, part way through the application. There is no need for the client to wait on a response from the system since the data will not be needed immediately. It can be assumed that the lower level service has taken care of the event without waiting for a response and slowing down the interface. A synchronous call will be made to pull that data from the service once the user reaches the Vehicle's Screen.

AUTO QUOTE SERVICE TO DOWNSTREAM SYSTEMS INTEGRATIONS It is important to note that downstream systems will still need to integrate with Freedom Mutual’s Auto Quote service. These applications include Interactive Voice Response (IVR) applications, Computer Telephony Integration (CTI) applications, Financial/Billing Systems, Claims Systems, Information Management, and many others. Many of these depend solely on leveraging the data generated by the Auto Quote service and it is critical that these systems are not impacted as they will continue to pull data from the existing master database.

As the current Freedom Mutual SOA architecture is very large, a full conversion to microservices will approximately be a five-year effort. It will be critical to Freedom Mutual that, as the transition to microservices occurs, any new microservices interoperate with the existing SOA services and applications seamlessly. During the POC and the full migration, the data from the microservice databases will be copied to the legacy master database and vice versa using the concept of a data pump so that data between legacy applications and the newly rewritten applications will stay in sync. 15 Once the full migration is complete, a shared database approach will be used utilizing the master database and the same data pump. Leveraging a




shared database makes it easy for downstream applications to share data and report on it, but does not address decreasing dependencies, testing, and data schema impacts if something is changed.

To remedy this, outside applications will not be accessing databases directly. For reporting, and other requirements which make it necessary to have a full view of the data in the Auto Quote application, a microservice will be created that is dedicated to maintaining an updated view of the data within the application. This microservice will subscribe to all relevant events, and update the view it produces accordingly.16 This service will allow for queries, such as Customer Info searches, when data extends across multiple services.17 The downstream applications will call into that service, which will return all the required data that the application needs. It will be a single point of contact for all external applications to interact, and will remove the impact of schema updates, regression testing, and data changes that normally come along with shared databases. Other options that will be implemented include application-side joins, allowing for the API to complete the data views by retrieving data from multiple services.18

As the transformation to a microservices architecture takes place, the integration with legacy services that have not been converted will need to be implemented to avoid breaking any existing interfaces, and limit impacts during the transition. Coexisting endpoints that permit new and old processes to be used until a full transformation of that service has been completed will ensure a smooth transition, allowing development teams to begin deploying and upgrading microservices independently. This also makes it possible for teams to deliver microservices faster, and allows existing services to leverage existing interfaces. Once all of the consumers of that endpoint are no longer using the old endpoint, a cleanup effort will be done to remove them, and any associated code, leaving a clean microservices structure that will have minimal impact while being implemented.

ACQUISITION INTEGRATIONS Another area of integration that must be considered is how newly acquired companies become integrated with Freedom Mutual’s Auto Quote service. All acquisition work currently in progress will make updates to the existing SOA Auto Quote services. As the migration to microservices takes place, dual updates to new and existing services will take place until the transition to the new microservices are completed. New acquisitions will be built leveraging all microservices that have been separated from the SOA framework, mixed with existing services until the full cutover is complete. Once services are updated, data migrations of existing customer information will be done during customer policy renewal time, utilizing specific algorithms that adjust coverages to match Freedom Mutual’s offerings. New business transactions will be done through the acquisition specific client, but will leverage shared microservices which differentiate data needs and rating factors based on the regulatory differentiator, Company Code.

As the migration to microservices takes place, the newly transformed microservices and their corresponding APIs make integrating a new acquisition easier because it is more flexible, decoupled, and less impactful on existing Freedom Mutual design. Additionally, leveraging individualized databases by service, and also using a NoSQL database that does not have a schema, means that integrating acquisition data becomes easier because there is not a rigid data structure to migrate to.




2.5. DATA DESIGN AND MANAGEMENT DATA STRUCTURES Freedom Mutual currently has three main data structures for the Policy Management applications (Figure 4 below). These data structures also intercommunicate with each other as well so no single structure is handled in isolation.

1. Users are people or groups that need non-customer access to the system. Currently there are three types of users (employees, partners, and agents). The types can be to expanded as needed, e.g., third party entity users etc. Different user types are assigned different levels of access to the data as their job requires.

2. Policyholders are existing customers who hold policies and potential customers shopping for new policies. There are currently three types of policyholders: auto, property or both. While there are some additional policy product lines, they are outside the scope of this project. The auto entities have sub-sections to break out the specific information on the vehicles or “asset” being covered and a separate structure holding driver history. The property data structure contains details on the property being covered, such as the age of the property and its location.

3. Policies cover the actual policy the policyholder has purchased. As with Policyholders, the Policy data structure is also broken into “auto” and “home”. However, each of these structures further breaks into “rates” and “discounts” sub structures to cover the many actuarial variables that go into making the policy.

The publically accessible data is accessed using RESTful interface utilizing the WS02 API manager over HTTP either in a JSON or XML format depending on the needs of the consumer. Data access includes both writing and retrieving data from the users on the portal as well as internal calls amongst the microservices.

Figure 4: Data Structures

DATA STORAGE The data will be stored in small databases tied to each microservice. As an example, the Vehicle microservice will have a PostgreSQL relational database storing data on thousands of vehicles and all the different options for those vehicles such as safety features. The Zip Code service will not only have location data stored in its NoSQL MongoDB database, but it will also include the products available for that location (e.g. Auto insurance may not be available in all states due to risk or regulatory decisions). While the data will be split into different databases the concept of foreign keys will still exist to tie the data together. Instead of traditional foreign keys in a RDBMS, the concept of foreign keys will be handled by the APIs exposed by WS02. The




Freedom Mutual Inc. System

Auto Quote microservice will pull data from the Zip Code and Vehicle microservices as well as its own local MongoDB database. Communication between microservices utilizes RabbitMQ and returns a quote.

Having the data segregated into individual databases will also allow for better scaling. An example of this is that the microservice storing Zip Code and product information may periodically add or remove records, but it would occur infrequently. Customers, on the other hand, would be frequently updated as people quoted and subsequently purchased new policies. The individual database attached to the Customer microservice could be scaled up without impacting any of the other databases. The robust partition tolerance available in MongoDB also will allow Freedom Mutual to scale the data horizontally across many different nodes as load requires.

With every data event, the data from the different microservices’ databases will be sent as an asynchronous data exchange to the main, master database using a data pump. This critical data synchronization will occur to keep the legacy master database in sync with the new individual microservice databases allowing both the new architecture and the legacy architecture to operate side by side. Once the full migration to microservices has been completed the data pump will continue to function as not every backend legacy application (e.g. IVR, telephony) will be converted to a microservices architecture. Data access and confidentiality is maintained and managed through the WS02 API manager through the use of role based security. Each consumer of a public API (e.g. web client, 3rd party, etc.) will have access granted based on the role of that consumer and secured through common OAuth2 standards.

2.6. SOLUTION DEMONSTRATION The following is an example of the proposed solution. A customer logs in to manage their policy via the policy management Client Application of Freedom Mutual Inc. (screen is depicted in Figure 5 below).

Figure 5: Freedom Mutual Inc., Customer Facing Client Application

When the customer selects a function to manage their policy, e.g., “Quote or Make Changes to Drivers, Vehicles, Coverage, or Contact Info” (highlighted with red box). They are taken to the screen depicted in Figure 6 below where different parts of the management function access different microservices.




JEEJEEJEEJEEJEE

CUSTOMER FACING(WEB/MOBILE)

AGENT PORTAL APIACCESS3RD PARTY

IOT /WEARABLES

CLIENTAPPLICATIONS

MICROSERVICES

MONGO MONGOMONGOMONGOPOSTGRES

CUSTOMER VEHICLE ZIP

DB

QUOTE DRIVER …JEE

EVENT STOREMASTER DATABASE

DATAGATEWAY

JEEDATA PUMP

DATA PUMP

RABBITMQ (PUBLISH/SUBSCRIBE)

EVENT

APIMANAGEMENT LAYER (WS02)

JEEJEEJEEJEEJEE

CUSTOMER FACING(WEB/MOBILE)

AGENT PORTAL APIACCESS3RD PARTY

IOT /WEARABLES

CLIENTAPPLICATIONS

MICROSERVICES

MONGO MONGOMONGOMONGOPOSTGRES

CUSTOMER VEHICLE ZIP

DB

QUOTE DRIVER …JEE

EVENT STOREMASTER DATABASE

DATAGATEWAY

JEEDATA PUMP

DATA PUMP

RABBITMQ (PUBLISH/SUBSCRIBE)

EVENT

APIMANAGEMENT LAYER (WS02)

Acquired Company SystemCITIZEN’S INSURANCE

Citizen’s – the one to insure you and everything you own!

Figure 6: Sample Customer Policy Management Screen Mapped to Microservices

Thus changes to any one portion of the management functions would impact only the relevant microservices.

ACQUIRED COMPANY IMPACTS The use of microservices also makes integration of acquired company system functions within the Freedom Mutual infrastructure. Figure 7 depicts the policy management screen at a fictional acquired company “Citizen’s Insurance” (see highlights in red box). A different front-end client application is required to maintain the “Citizen’s Insurance” brand vis-à-vis the customer facing application. However, the acquired company front-end now uses the API Management Layer and calls the same microservice.

Figure 7: Acquired Company Front-End & Policy Management Screen Mapped to Microservices

Freedom Mutual Inc. System

CITIZEN’S INSURANCE




If a function of the acquired company’s policy management screen differs and necessitates changes to the microservices, then the changes are limited to the microservices invoked by the function and not to the entire monolithic Freedom Mutual infrastructure. This makes integration of new acquisitions simpler and more cost-effective – an important requirement of Freedom Mutual’s “growth by acquisition” business strategy.

PART 3. IMPLEMENTATION PLAN

3.1. SOLUTION DELIVERY ROADMAP Idea Central’s team has recommended replacing Freedom Mutual’s current Service Oriented Architecture (SOA) IT environment with large, coarse grained services with a Microservices Architecture shown below in Figure 8. The primary microservices identified for implementation are those that are key for ‘Quoting’ functions for new and renewal insurance policies. Microservices migrating in the First Phase are as follows.

• “Customer” service

• “Vehicle” service

• “Zip” service

• “Driver” service

• “Quote” service Figure 8: Recommended Microservices Architecture for Freedom Mutual

The First Phase of the implementation aims to put in place all the key infrastructure including – API Management Layer, ‘Quoting’ microservices layer, RabbitMQ event management, Event Store, Data Pump & Data Gateway and any modification to the Master Database infrastructure. The First Phase is expected to take about 9 months as shown in Figure 9 below.

Figure 9: Implementation Timeline for move to Microservices Architecture (First Phase completed in 9 months).

Team 2: Dave Waltz, Rabindar Subbian, Scott Pullen, Kelley Kage, Jim Goodspeed Part 3: Implementation Plan

FREEDOM MUTUAL INSURANCE, INC. - MARCH 2016 PAGE 22

WEEK: 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 36 37 38 39 403 "AGENTPORTAL"Application-Mod/Re-write

4 Migrate"CUSTOMER"Microservicea Develop"CUSTOMER"Microserviceb Setup&IntegrateMongoDBc SetupWSO2APIManagementLayerd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"DevelopmentandDeploymentg "EVENTSTORE"Setuph "MASTERDATABASE"Modsi DataMigration

The implementation includes an initial one month “Setup” period which includes implementation and configuration of Docker, Kubernetes cluster, a Jenkins Continuous Integration/Delivery framework and RabbitMQ event management setups. Detailed timeline is included in Appendix E.

This is followed by a 5-month implementation window for the “Customer” service in the First Phase (Figure 10) which deals with the data and rules associated with the ‘Customer’ entity. This step is likely to take longer for the first microservice compared to subsequent microservice development and migrations. During the second month, work will start on the modifying the “AGENT PORTAL” (client application) to take advantage of WS02 API management services and the microservice based architecture. The portal will be cut over to leverage the new microservices once all of the ‘Quoting’ function related microservices are completely developed and have been tested.

Figure 10: Implementation Timeline for “Customer” service (1st microservice) – 5 months to implement the first microservice



WEEK: 26 27 28 29 30 31 32 33 34 35 36 37 38 39 403 "AGENTPORTAL"Application-Mod/Re-write

5 Migrate"QUOTE"Microservicea Develop"QUOTE"Microserviceb Setup&IntegrateMongoDBc WSO2APIManagementLayerIntegrationd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"Integrationg "EVENTSTORE"Integrationh "MASTERDATABASE"Modsi DataMigration

6 Migrate"VEHICLE"Microservicea Develop"VEHICLE"Microserviceb Setup&IntegrateMongoDBc WSO2APIManagementLayerIntegrationd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"Integrationg "EVENTSTORE"Integrationh "MASTERDATABASE"Modsi DataMigration

7 Migrate"DRIVER"Microservicea Develop"DRIVER"Microserviceb Setup&IntegrateMongoDBc WSO2APIManagementLayerIntegrationd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"Integrationg "EVENTSTORE"Integrationh "MASTERDATABASE"Modsi DataMigration

Other essential infrastructure will also be built out in parallel with the microservice development. These tasks include configuring RabbitMQ for the first microservice (“CUSTOMER”), development of the “EVENT STORE” database and the “DATA PUMP” for pushing data from services’ databases to the Master Database (Figure 9). These tasks take place in an iterative fashion and will continue to be expanded with each delivery milestone that is achieved.

Once the “CUSTOMER” microservice is completed, other relevant services are worked on and implemented in parallel over the next 3 months. While we estimate that, on average, each microservice will take approximately three months, differing levels of functionality and complexity may increase or decrease each implementation by one to two weeks. After the POC is complete and the teams are more familiar with the technology, the Development team's velocity will likely decrease this further.

This provides the significant advantage that Freedom Mutual will gain by accomplishing its IT goal of rapid integration of new business acquisition and supports the business strategy of “growth by acquisition”.

A month long data migration (tasks “5i”, “6i”, “7i”) accomplish the “go-live” that ends the First Phase.

Figure 11: Implementation Timeline for Additional services in First Phase – 3 months to implement the subsequent microservices in parallel

RISK AND RISK MANAGEMENT

RISK IMPACT PROBABILITY MITIGATION

If the current monitoring and System Health Baseline are not enhanced, the application could not be functioning correctly, and no one would be aware.

Medium Low • Elastisearch, Logstash, Kibana (ELK) stack for log aggregation, monitoring, visualization, and alerts.

• DevOps and Teams responsible for maintaining a service determine the metrics to track to monitor system health.

• Performance of system must meet current ‘Quoting’ application benchmarks.



RISK IMPACT PROBABILITY MITIGATION

Complicated Production Environment/Process may cause us to miss a step in the deployment process when automating.

High Medium • Docker to simplify service environment. • Kubernetes for cluster management and efficient

resource utilization. • Automated testing through Continuous Integration.

Deploying feature or function could negatively impact other production functions.

Medium Low • Kubernetes for deployment of Docker images onto cluster. o Rolling Deployment (“canary in a coal mine”) o Zero-downtime o Rollbacks upon failure

• RabbitMQ facilitates running original system while installing new implementation.

If data is missed during the Data Migration and trying to maintain data synchronization is not done with all data, the current system will not be able to run in parallel.

High Medium • Run current database and service backed database in parallel.

• Maintain main database to support legacy services via Data Pump.

• Maintain event store to keep a history of data flow through message broker and ability to replay data to bring system to consistent state.

If the scope of the microservice migration is not managed closely new functionality will continue to be requested and will slow down the microservices implementation during the transition.

High Medium • Keep to a small subset of the overall application for the proof-of-concept. o Supporting infrastructure; Deployment model o Services: “Customer”; “Quote”; “Vehicle”; “Driver”

• Limiting scope allows team to build on lessons learned to accelerate future decomposition to services.

• Enhancements documented for new projects that need updates to new services.

Table 1 - Risks and Mitigation

In order to evaluate project health, we will be using the seven keys to project success (Appendix F). The seven keys to success provide an “effective and efficient approach assessing and evaluating your project status across the life cycle”.19 Each key is given a green, yellow, or red health status so stakeholders can get a high level view of the overall project health and know which areas to focus on. Each week the project team and the stakeholders will meet to discuss any issues that may have cropped up and evaluate the overall health of the project. This meeting will discover action items that need to be done by all parties involved to ensure a successful migration.

3.2. OPERATIONALIZATION In order to support the microservices architecture Freedom Mutual will need to move to a DevOps organizational structure. This change must be supported by senior leadership, including the development groups and the systems operations groups. In this new organizational structure, the team that creates the microservice will be responsible for testing it, running it and maintaining it, a practice implemented with great success at Amazon with their microservice conversion.20 A microservice architecture is a perfect fit for a DevOps organization due to the small independent nature of the microservices. Each microservice is small enough that it can have an independent team associated with it that will be completely responsible for its design, architecture, implementation and operation.21 One team may be responsible for multiple microservices depending on the



functional area and frequency of changes to those services. The additional responsibilities of these new teams ensure that the developers write robust quality products that are resilient to failure.

The development teams will utilize an Agile/Scrum methodology with two to three week sprints depending on the needs of the team. A typical microservice Agile team will consist of a product owner, scrum master, four developers, a quality assurance (QA) engineer and two business systems analysts.

The re-organization to DevOps will also reduce the responsibilities of the data center operations staff. In the current organization a large number of off-shore contractors perform application deployments. With this responsibility moving to the development teams, Freedom Mutual will see a reduction in off-shore contractors. Regular full-time employees responsible for maintaining the physical hardware for these new microservices should see minimal impact.

The building, testing and deployment of the microservices must be fully automated. Idea Central will implement Jenkins for its Continuous Integration and Delivery solution (Figure 12 below). At the end of the migration there will be hundreds of microservices with many interdependencies, so it will be important to automate unit testing, service testing, end-to-end testing and especially contract testing, where the interactions between the

microservices and their clients are verified.22 Automation must be given resources and treated as a high priority for the microservices project to be successful.

Figure 12: Continuous Integration and Continuous Deployment Process

When code is checked into version control Jenkins will automatically compile, create Docker artifacts, test and then deploy to a staging environment where further automated integration and contract testing can be done. Jenkins will also be responsible for initiating weekly automated security scanning using Checkmarx and performance scanning using BlazeMeter. Idea Central will build an automated process that will allow development teams to provision Docker enabled servers themselves either from an on-premises cloud environment or a public cloud such as Amazon Web Services (AWS). A lighter weight release management process can be used due to the level of automation that will be put into place as well as the ability to isolate changes. If a microservice build has passed all Jenkins automated tests it will be deemed ready for production. The Product Owner associated with the microservice team will have responsibility for making the determination of when to release it.

Log monitoring will be achieved using the Elastisearch, Logstash, Kibana (ELK) stack. From an operational point of view ELK can be used for a number of day-to-day tasks from uptime reports and system health to



production testing and verification. While the logs will be openly available, the teams responsible for each microservice will be responsible for monitoring the logs and receiving the alerts, via the Watcher plugin, that they generate. Additionally, alerts will be sent in parallel to the Service Desk monitoring dashboard. Freedom Mutual already makes use of Introscope, another monitoring tool, in its SOA environment, which provides valuable information regarding the underlying health of the JVMs running the microservices. As with the ELK stack, the teams responsible for the microservices will also be responsible for monitoring and receiving Introscope alerts. Finally, Topbeat will be used to monitor system health such as CPU and memory. The development group will also be responsible for receiving the Topbeat alerts, but the data center staff operating the hardware and operating systems will also share in this responsibility, as they do now in the current SOA environment.

The “Service Desk” will be the first point of contact for any and all production incidents that might occur with any of the microservices (Figure 13 below). Both the ELK stacks including Topbeat and Introscope will

be reporting data and alerts to a dashboard monitored by the service desk. The Kubernetes cluster is able to respond to certain conditions on its own, such as a process running out of resources (CPU or memory for example) and can then spawn additional instances of that microservice Docker container to share the load. In parallel, the system would send an alert to the dashboard to notify the service desk. In the event that additional instances are required, the system will stop the auto creation of additional instances at five. More than that could indicate a runaway process or other ‘looping’ condition. This would also trigger a critical severity alert to the service desk for immediate response/action. The service desk is responsible for first level support, either reported by users or via alert system from the microservices themselves. This first level of support triages any issues. If it is deemed that there is a code issue or the problem escalates to become a more critical issue, the service desk will then engage the formal escalation process. When the service desk team needs additional resources to resolve the escalation, they will contact the corresponding development team that owns the process that is involved with the reported incident. From there, the development team will work with the service desk team to resolve the incident.

3.3 USER ENABLEMENT The microservices cut over will be transparent, and have no end user impact. Acquisition impacts will be handled by development teams and training teams aligned specifically to the project. Instead of focusing on end users for this project, the focus will be on the developers. All existing security, authorization, and authentication will leverage what is used for Freedom’s existing application. The focus will encompass a communication plan, training, and knowledge management plan. For communication and training, the focus will be on the new technologies being introduced to the development teams, and the process changes that they will need to be made aware of. Training will be done leveraging the company’s existing online education tools. The Training Development team will create all training materials and online modules. Additionally, a knowledge base Wiki will be developed with links to training tools, tips, and how-tos.23 Finally, the development team participating in the First Phase of this project will also act as trainers and mentors to new teams as they are on-boarded with the new architecture and organizational structure. Access, roles, and privileges to the new technologies will be as follows.

Figure 13: Incident reporting and handling process



1. Access will be granted to developers based on current privilege group assignments aligned to them. 2. Roles and privileges needed in new tools/technologies will be assigned to developers based on their

job title and current group alignments for the existing application. A breakdown of roles is as follows in the table below.

JOB TITLE ACCESS LEVEL BY APPLICATION RIGHTS

Release Manager

Read Only for Development Tools, Read/Write access to Deployment Tools

Will have read/write access and Admin access to all Microservice deployment tools. Read only access for all development tools.

Software Developer

Read/Write access to all Development Tools, Read/Write access to Databases

Will have read/write and Admin access to the source code systems for appln. devl. analysis, configuration, and tuning.

Data Analyst Admin Access to all Databases Will have read/write and Admin access to the source code systems for data analysis, configuration, and tuning.

Project Manager

Read Only for Development Tools, Read/Write for Task Mgmt. Tools

Will have read/write access to Task Management Tools. Read only access for all development tools.

System Administrator

Admin Access to Monitoring, Logging, and Environment Configuration tools

Will have read/write access and Admin access to all monitoring, logging, and environment configuration tools.

Table 2 - Roles and Privileges (New Tools / Technologies)

3.4. SUCCESS METRICS Success Metric chart base on five-year project completion is as follows.

METRIC EXPECTED RESULTS

Time to regression test and deploy new features/functionality.

Labor required to implement new features is reduced by 90%. Offshore deployment staff reduced with functionality moving to DevOps teams.

Eliminating offshore deployment team. In the old environment, deployment testing and rollout was performed by an offshore development team. This team will no longer be needed as that function is being absorbed by the DevOps teams.

Labor Reduction with integration of new acquisitions. Labor required for new acquisitions is reduced by 65% due to reduced integration time from 2 years to 9 months with a total reduction in project cost of $26 million*.

Application performance improvement with reactive monitoring in place.

Uptime for applications maintained at 99.99%.

Reduced deployment times. No more complex / ‘Moon Shot’ deployments. Deploy on demand. Services are independently buildable and deployable.

New features/functions are able to be deployed in hours at any time.

Table 3: Success Metrics

* Based on 200 engineers working 4,160 hours @ $50/hour = $41.6 million.24. New process only needs 1,560 hours which would save $26 million.



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE i

APPENDICES

APPENDIX A: ELK STACK The ElasticSearch, Logstash, Kibana (ELK) log and monitoring stack supporting the microservice infrastructure at Freedom Mutual.



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE ii

APPENDIX B: MICROSERVICE DIAGRAM

GENERIC MICROSERVICE IMPLEMENTATION

APPENDIX C: SUPPORT TOOLS & EVENT MANAGEMENT

SUPPORTING TOOLS FOR THE MICROSERVICES IMPLEMENTATION.

Tool Function

Jenkins Automation server to facilitate Continuous Integration/Continuous Deployment and other routine jobs

Docker Containerized application environments

Gradle Build automation

TestNG Test framework for JVM based languages

Elasticsearch JSON based search store using Lucene

Logstash Centralized data parsing

Kibana Visualization on top of Elasticsearch

Filebeat Forwards log entries to logstash for processing

Topbeat Forwards the output of running `top` to logstash for processing

Watcher Generates alerts based on Elasticsearch queries

Contd. on next page …



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE iii

RABBITMQ EVENT MANAGEMENT INTERACTIONS (A)

Contd. on next page …



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE iv

RABBITMQ EVENT MANAGEMENT INTERACTIONS (B)



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE v

APPENDIX D: TOOL COSTS

OPERATIONAL TOOLS All license and support costs are list prices. Idea Central and Freedom Mutual will negotiate on pricing to reduce the overall expenditure.

Name Function License/Support

GitHub Enterprise Source and Version control $2,500 per 10 users per year

Jenkins Operations Center Continuous Integration Automation

$7,500 per year.

Kubernetes Infrastructure management for Docker

$450 per node per year.

Elastisearch, Logstash, Kibana (ELK) Stack

Log Monitoring and aggregation No additional support required.

Introscope JVM Monitoring Covered by existing MSA company license.

Jira Agile & Issue Management $18,000 for 500 users.

Checkmarx Security scanning $230,000 per year.

APPENDIX E: IMPLEMENTATION TIMELINES

“SETUP” PHASE

WEEK: 1 2 3 4 51 TeamOnboarding

2 Pre-ImplementationSetup

a ConfigureDocker

b Kubernetessetup

c Jenkins(setupsansjobs)

d RabbitMQSetup “Setup” Phase Detailed Tasks and Timeline



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE vi

WEEK: 26 27 28 29 30 31 32 33 34 35 36 37 38 39 403 "AGENTPORTAL"Application-Mod/Re-write

5 Migrate"QUOTE"Microservicea Develop"QUOTE"Microserviceb Setup&IntegrateMongoDBc WSO2APIManagementLayerIntegrationd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"Integrationg "EVENTSTORE"Integrationh "MASTERDATABASE"Modsi DataMigration

6 Migrate"VEHICLE"Microservicea Develop"VEHICLE"Microserviceb Setup&IntegrateMongoDBc WSO2APIManagementLayerIntegrationd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"Integrationg "EVENTSTORE"Integrationh "MASTERDATABASE"Modsi DataMigration

7 Migrate"DRIVER"Microservicea Develop"DRIVER"Microserviceb Setup&IntegrateMongoDBc WSO2APIManagementLayerIntegrationd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"Integrationg "EVENTSTORE"Integrationh "MASTERDATABASE"Modsi DataMigration

WEEK: 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 36 37 38 39 403 "AGENTPORTAL"Application-Mod/Re-write

4 Migrate"CUSTOMER"Microservicea Develop"CUSTOMER"Microserviceb Setup&IntegrateMongoDBc SetupWSO2APIManagementLayerd ConfiguredeploymentintoKubernettese ConfigureJenkinsjobstohandleautomationf "DATAPUMP"DevelopmentandDeploymentg "EVENTSTORE"Setuph "MASTERDATABASE"Modsi DataMigration

FIRST PHASE: MICROSERVICES IMPLEMENTATION

First Phase: “Customer” Microservice Detailed Tasks and Timeline

First Phase: Additional Microservice Detailed Tasks and Timeline



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE vii

APPENDIX F: SEVEN KEYS

SEVEN KEYS TO PROJECT SUCCESS

Example of the seven keys of success 25



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE viii

APPENDIX G: “QUOTE” FUNCTION SEQUENCE

SEQUENCE DIAGRAM OF “QUOTE” FUNCTION USING MICROSERVICES Description of the flow of the sequence diagram is detailed in page 11 of “Section 2.2. Architectural Details”.



FREEDOM MUTUAL INSURANCE, INC. - MAY 2016 PAGE ix

REFERENCES

1 Agile coding in enterprise IT: Code small and local. (2014). Retrieved May 4, 2016, from http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.html Retrieved from PwC Technology Forecast online publication website.

2 Research and Development Engineer Salaries. (n.d.). Retrieved April 29, 2016, from http://www1.salary.com/Research-and-Development-Engineer-Salary.html

3 Newman, S. (2015, February 2). Building Microservices. " O'Reilly Media, Inc.", p. 6, 7. 4 Newman, S. (2015, February 2). Building Microservices. " O'Reilly Media, Inc.", p. 7. 5 Agile coding in enterprise IT: Code small and local. (2014). Retrieved May 4, 2016, from

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.html Retrieved from PwC Technology Forecast online publication website.

6 Leymann, F., Fonseka, J., Malalgoda, S., Dias, N., Medagammaddegedara, S., & Amarasinghe, M. (2016). WSO2 Rest API Design Guidelines (Tech.). Retrieved May 3, 2016, from WSO2.com website: http://wso2.com/wso2_resources/wso2-whitepaper-wso2-rest-apiss-design-guidelines.pdf (WSO2 White Paper)

7 "What Is CAP Theorem? - Quora." 2016. 16 Mar. 2016 https://www.quora.com/What-Is-CAP-Theorem-1

8 Features – RabbitMQ, (2012). Retrieved March 12, 2016, from https://www.rabbitmq.com/features.html. 9 Newman, S. (2015, February 2). Building Microservices. " O'Reilly Media, Inc.", p 96-98. 10 The MongoDB 3.2 Manual — MongoDB Manual 3.2 (2103). Retrieved March 12, 2016, from

https://docs.mongodb.org/. 11 (2015). 5 Key Benefits of Docker: CI, Version Control ... - DZone. Retrieved March 13, 2016, from

https://dzone.com/articles/5-key-benefits-docker-ci. 12 "Kubernetes - Accelerate Your Delivery." 2014. 2 May. 2016 http://kubernetes.io/ 13 Newman, S. (2015, February 2). Building Microservices. "O'Reilly Media, Inc." p. 79 14 Building Microservices, p.67 15 Newman, S. (2015, February 2). Building Microservices. " O'Reilly Media, Inc.", p. 97. 16 Richardson, C. 2014, “Pattern: Database Per Service,” GitHub/Kong [Online]. Available:

http://microservices.io/patterns/data/database-per-service.html 17 Richardson, Chris. December 4, 2015, “Event Driven Data Manangement for Microservices,” NGINX

[Online]. Availabile: https://www.nginx.com/blog/event-driven-data-management-microservices/ 18 Agile coding in enterprise IT: Code small and local. (2014). Retrieved May 4, 2016, from

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.html Retrieved from PwC Technology Forecast online publication website.

19 Chu, A. (2014, August 14). Project Management – 7 Keys to Success. Retrieved April 22, 2016, from https://www.linkedin.com/pulse/20140814092910-287655312-project-management-7-keys-to-success

20 Gray, J. (2006, May). A Conversation with Werner Vogels. ACM Queue, 4(4), 16-21. Retrieved April 22, 2016, from https://queue.acm.org/detail.cfm?id=1142065. Interview with Werner Vogels, CTO, Amazon.com, on Webservices & Amazon Technology Platform.

21 Newman, S. (2015). Building Microservices, p. 27. O’Reilly Media, Inc. 22 Newman, S. (2015). Building Microservices, p. 144. O’Reilly Media, Inc. 23 Hamermesh, R. G., McFarlan, F. W., Keil, M., Morgan, M., Katz, A., and Laborde, D. (2011).

Computerized Provider Order Entry at Emory Healthcare. Harvard Business School General Management Unit case, (311-061), p 6. Harvard Business School: Cambridge, Mass.

24 Research and Development Engineer Salaries. (n.d.). Retrieved May 03, 2016, from http://www1.salary.com/Research-and-Development-Engineer-Salary.html

25 Jeacocke, S. (2013, January 10). The seven keys to successful projects? Eating the Elephant Blog. Retrieved April 22, 2016 from https://elephanteaters.wordpress.com/2013/01/20/the-seven-keys-to-successful-projects/

Capstone Seminar in Digital Enterprise , Ph.D. Teaching...

Documents

Transcript of Capstone Seminar in Digital Enterprise , Ph.D. Teaching...