Evolving a monolithic Java EE application to microservices
•Download as PPT, PDF•
0 likes•896 views
Microservices meet legacy applications. What approaches can you use to break down a Java EE monolithic application?
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (11)
Similar to Evolving a monolithic Java EE application to microservices
Similar to Evolving a monolithic Java EE application to microservices (20)
Recently uploaded
Recently uploaded (20)
Evolving a monolithic Java EE application to microservices
- 1. Evolving a monolithic Java EE application to microservices Microservices meet legacy applications Erin Schnabel schnabel@us.ibm.com @ebullientworks
- 2. Agenda • Introduction • Rules of engagement • Service decomposition • An evolved image service • Liberty app accelerator • Summary and Questions Explore and demonstrate how JEE applications can evolve to a microservices architecture, using Plants By WebSphere (PbW) as a sample application. 2
- 3. Microservices Background and Overview PCM-2026: Microservices: Buzzword Bingo or Real-World Problem-Solver? Mandalay Bay Solution EXPO - Engagement Center 232 06:30 PM - 06:50 PM Erin Schnabel / Isabell Sippli PCM-2026: Microservices: Buzzword Bingo or Real-World Problem-Solver? Mandalay Bay Solution EXPO - Engagement Center 232 06:30 PM - 06:50 PM Erin Schnabel / Isabell Sippli
- 6. Rules of Engagement General principles 6
- 7. Rules of Engagement: Development • Know what you want to achieve: – Strangle / Create new – Cloud? • Change as little business logic or function as possible • Be prepared for a dynamic new future
- 8. Rules of Engagement: Testing • Test for parity, not for correctness – Does the new thing work the same as the old thing? – Be consistent with the old monolith • Unit/Functional tests are not the whole story – Performance/Throughput requirements – Existing Integration / QA environments 8
- 9. Rules of Engagement: Context • What APIs are you going to create ? – Internal? External? $$? • Where is your data and in what format • How will you find your new services? – What is the wiring (gateways, proxies, …)? 9
- 10. Rules of Engagement: Java EE • Many aspects of Java EE are inward facing – Assumptions about things contained within the module • CDI or any other injection technology needs a second look – Do you know what is being injected? – Do you know what those things are having injected? 10
- 12. Functional decomposition • Decide what to move where based on what it does • Traditional approach, often a good starting point • Relies on well defined component boundaries
- 13. Technology-based decomposition • Look at EE specific technologies • Use the migration toolkit: – view class structures and – identify EE technologies in the application 13
- 14. Decomposition: Checkpoint • Is what I have good enough? Is there sufficient return on investment ? − New API = new business ? − Hardware / software savings ? • Do you have the right skills? 14
- 15. A revised image service 15
- 17. Image service • Selected because – It is mostly static content – Not business critical – Contains no proprietary code or sensitive data • Value – Storage / hardware savings (on prem) when moved to cloud – Potential re-use of the service in other applications
- 18. Image service with shared data (2) Developing a new API to expose image data − Built with the Liberty app accelerator − Database is still shared with the original application − Defines the externals that will be used by the monolith going forward REST: simple synchronous calls 18
- 19. Separate image service (3) • The service now properly owns its own data • Externalized location – Service discovery, or – Well-known location • Considerations: Protect the monolith – API Gateway – Circuit breaker / bulkhead 19
- 20. Cloud-based image service (4) • Image service hosted in Bluemix – Availability – Scalability – Management – Statistics • Monolith – Remains on-premises – Move to the cloud (?!) 20
- 21. Liberty app accelerator A quick start for Java-based microservices 21
- 22. Liberty app accelerator: http://wasdev.net/accelerate • Java-based microservice using Liberty built and deployed in < 10min Application configuration Code snippets Possible deployment options: − Local − Bluemix
- 23. Summary 23
- 24. Summary • Microservices are not free • You can build microservices with Java EE • Microservices != Cloud • Resources: – http://wasdev.net for all the things • http://wasdev.net/docs/microservices – Github Samples: https://github.com/wasdev?query=pbw – Liberty app accelerator: http://wasdev.net/accelerate
- 25. Create: Cloud native apps and microservices 25 Play GameOn do SmartArt cycle More Information: 2116 Creating 12-Factor Applications with IBM WebSphere Liberty on IBM Bluemix: A Practical Guide Thursday 9:30-10:15 Erin Schnabel
- 26. Notices and Disclaimers 26 Copyright © 2016 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law
- 27. Notices and Disclaimers Con’t. 27 Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
- 28. Thank You Your Feedback is Important! Access the InterConnect 2016 Conference Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.
Editor's Notes
- This is where we examine whether or not it&apos;s going to make sense to evolve your monolith. What are the benefits you&apos;re going to see vs the cost ? In the end you may be better off starting from scratch or (more likely) with a hybrid solution. Of course, if you&apos;re going to do it from scratch then bring out Game On !!!!
- Principles that can be applied for development Change little : you have something that works and is important to your business. The more of this you change the more risky it will be. Avoid the &apos;opportunity&apos; to add some more function along the way ! Not the cloud : talk about hybrid being the likely result. You may have proprietary things you don&apos;t want hosted elsewhere, sensitive data that can&apos;t be moved or links to existing systems that will fail to work. Strangle etc. : lots of nice new shiny things are going to be created i.e. new services, use new protocols etc. but whatever, you will need to change the monolith. So you&apos;ll need the skills/access to do so. Things are going to move : This really means two things: 1. The shape of the application&apos;s architecture will change. Evolution will likely involve hosting new services in a variety of places and locations. You may even end up hosting the remaining legacy app in the cloud and having the new services internal only ! So, things are going to move – be prepared – externalisation of config / service registries help here. 2. The running application is likely to be more dynamic. Service-based architecture will mean that parts of the app may come and go, and the application as a whole needs to cope with that. Quite literally, everything can move and you need to be prepared for when it does.
- Partiy : we&apos;re evolving, so the first step is parity i.e. does the new thing work the same as the old. This is not the same as does it work as it&apos;s supposed to ! You are likely to uncover things that are wrong – if you fix them you may break your existing systems that connect to the monolith. You are also changing more things at the same time. You can always change your tests later. If following TDD, then the tests will pass for parity, but fail when you fix it, so you can then change the tests. Tests in a bubble : unit and functional tests are only one aspect. Once these pass it&apos;s not job done, need to think about non-functional tests/requirements such as SLAs and performance/throughput. Monolith change : If you have existing tests, then they will need to change as the monolith changes.
- APIs : the API economy – you are now going to be creating new ones – perhaps based on the old ones. Opportunity to create new business offerings / integration via any API you create. Will you be able to make money from your new API ? You will need to think about things like versioning / updating. With a monolith component API changes can be largely invisible, with MS you are potentially providing a whole set of new ones that are accessible from outside of the application. Data : what is it and where is it ? Will you need to partition the data in some way between services, do some services need access to the same data ? Do you have SQL or No-SQL requirements or a mixture of both. Will you want to still host the data yourself or can you now get it from a new service e.g. postcode lookup may be something you do via an internal system, but could now do it via a public service from USPO / Post Office. Wiring : remember, things are going to move – so you&apos;re going to need to find and connect to them. Do you have blockers / requirements in your organisation that feed into any decisions here?
- In Plants By WebSphere this could be the ordering system or the user registry. Ideally, you could pick up all the classes that make the ordering system and put them elsewhere, and once you wire them together with REST or messaging everything else works as is. Reality is likely to be that classes are shared, code may have interdependencies that are complex and this may make a purely functional decomp very hard and error-prone.
- We are working in a Java EE / WAS environment, so can use some additional tools. The screenshots are taken from the migration toolkit. The technologies can map to obvious services e.g. servlets and EJBs can provide you with a good starting point. The class interactions are useful to show not only what needs to be taken across in the service, but also highlights potential problems where services reference the same component – or indeed, may expose the requirement for another service.
- Provide a checkpoint / stop and think point after identifying potential services. Reflect on what it is actually going to cost you to implement the services, compared with what you already have. You should also be able to clearly identify the business benefits of the evolution – whether that is resource savings, re-use/consolidation or new business opportunities.
- Look in detail at a service from Plants by WebSphere. It&apos;s not the most complicated example, but is generic enough to cover almost all the considerations you need to take into account.
- The general flow of the evolution is left to right. Starts with limited split out of functionality, with hard coded knowledge of where things live. Finally evolving to a fully decoupled cloud service. More detail on the following slides.
- Reasons why the service was picked – also these are good characteristics to look for in your first attempt as the risk is minimal. Obviously not so important if you already have the required skill sets. The business value will come from hosting the images in the cloud and releasing hardware costs. You could also potentially re-use a generic image service across other products.
- Own data, but a single service instance, so no data issues just yet. Route from the monolith to the service is via external configuration / factors. A service registry is used to hold where to go to, which can be either directly to the service or via a well known location that in fact is another proxy to the service. These patterns now need to be considered - API Gateway : need to call out to the service (reverse proxy) - Circuit breakers – however, this call to the service might fail - Bulk heads – if it does fail, only that segmented part of the application doesn&apos;t work, you don&apos;t have a complete failure.
- Options for the monolith are to leave as a hybrid with business critical/Systems of Record under local control. Alternatively, by the time you finish the monolith may no longer be a monolith and can in fact itself be hosted in the cloud.
- BIG UP SUPPORT FOR SPRING BOOT APPS