Reactive Microservices with RxJava part 1

Reactive Microservices with RxJava part 1

Admin aaTuesday, April 5, 2016

It's funny but some time ago reactive was used a word that relates to bad things all that changed now if you are reactive you are awesome. Besides the huge hype about reactive microservices lets rewind a little bit and remember what microservices are about. Microservices are about isolation and fine-grained functionality. Microservices are a specific and modern flavor of SOA. It's possible to have others flavors of microservices too.  Microservices are not for free and following this architectural approach you gain some issues, most of people really  don't know what are this issues. Which is very dangerous adopt something you don't know the issues :-)

Microservices Issues

There are several issues with microservices, IMHO here are some:

• Operational Complexity: Microservices require DevOps and Anti-Fragility. There is some considerable infrastructure burden like have a dedicated pipeline for each service. 
• Architectural Complexity: Mid-tier LoadBalancer, Discoverability, Registry, Centralized Logging, Fault-Tolerant Protocols, Dynamic Configuration are some of the new concerns MSA demands.
• Coupling: This is funny because is one of the most very first reasons to people go with microservices is have less coupling in your systems. Microservices deliver decoupling as long as defined the boundaries right otherwise you will have way more places to chance your code and this is how the coupling happens. Duplicate code is decoupled wrong contracts are not. 
• No Easy Joins: When we used to have a centralized database we almost always could do a central join that goes to 3-6 tables and was any to answer pretty much any question as long as volume was not involved(assuming an OLTP scenario). There are solutions for this at scale but they are more complex most because you have more data and often different and distributed databases per services.

Should I give up?

Well, to be fair it depends on the nature of your problem and how much scale and efficiency you need to have or will need to have. I'm an SOA guy. For sake of efficiency microservices are a better architectural solution but you need be careful with the level of granularity for instance I still not sure about all this Serverless movement and maybe that's too much. Remember the Left Pad Disaster?  Some folks are talking about nano-services which are the Serverless for me. 

Serverless Architecture Solutions Issues 

Serverless Architecture is great for mobile and IOT.  I have to confess the idea is pretty awesome but in practice there are several practical issues for instance:

• Time out: I'm AWS if your function runs for more than 5 minutes will be cut off. Right now there is no long running for you.
• Availability: AWS Lambda is not available in all Regions for instance right now you can't get into Brazil / Sao Paulo.
• Back Pressure and Timeouts: There is no built-in function to deal with timeouts and back pressure.
• Warm-UP VS COST issue: AWS might there down some of your functions if take some time to people call it so well you call you will see a warm up effect and this may degrade the performance. One way to fix it is pre-warm up all the functions time to time, however doing so you will make your solution COST way more.

Because IOT and Mobile, looks like Serverless is where people are doing but this is only one part of the market, of course , is a huge part but is not everything.  Right now I would not recommend run everything there. Another side effect of this is the NO OPS movement which gets stronger every day with more and more solutions like this one way to scale and make it the adoption easier. I don't need to mention there is no spec what so ever and you get a lock in easily. Meanwhile, the Enterprise companies are still fighting to slice the Monolith in the Mobile world things goes fast. Again this is a different reality with different problems. 

Being Reactive

If you are optimized for efficiency that's the way to go. Reactive means using way less resources and do more with less. Reactive is not easy or for free as well. In order to have full benefits, you need to be reactive end-to-end and this is hard because is easy to have blocking code all the way from the UI to the database. Being reactive could easily imply in rewrite all your drivers. Currently, there are 2 stacks that are very mature and efficient in the sense of reactiveness which are: Akka and the Netflix Stack. Netflix is working on new stack being fully reactive and leveraging the OLD gold techniques like IPC which is pretty interesting because it goes away from the REST and goes into the Native Drivers. Async programming is hard and error-prone I'm sure you heard about callback hell. Futures are not enough because they often are blocking and lead to callback hell. 

RxJava to Rescue

This code is  creating an Observable from a list of primitive integers and skipping the first 2 number and taking the next 4 numbers and adding 1 to each number and in the end printing in the console. 

RxJava is part of the Reactive Extensions. RxJava is a library for composing asynchronous and event-based programs without callback hell :-) using observables sequences for the JVM and Java. Rx is also known as the Observer Pattern. done in the right way.  Rx works in a push model instead of pulling and it is all around functional programming which and nice and great for composition. Netflix is a huge contributor of Rx and was the one to port form .NET to Java back into 2014. RxJava does have backpressure built in(window, buffer, sample) which is very useful. RxJava has all set of functions in order to do filtering, transformations, mapping and much more. Like everything in life RxJava has issues and drawbacks for me the worst things are:

• Debugging is hard: Do the asynchronous and Parallel nature.
• Error Handling is hard: It's easy to swallow some exception and just lost the whole context.

Should I use RxJava? Yes, Definitively. RxJava has zero dependencies, it's less than 1mb and its Non-opinionated about the source of concurrency (threads, pools, event loops, fibers, actors, etc). You can find more samples in my GitHub here.

Cheers,

Diego Pacheco

NetflixOSS the DevOps Stack for Microservices

NetflixOSS the DevOps Stack for Microservices

Admin aaSaturday, September 12, 2015

There are lots of people talking about microservices. IMHO I don`t most of people get it - Microservices are about Isolation, Idependence and Anti-Fragility and this are principles most of frameworks did not have. So the botton line is in the end of the day if you dont have this you are just doing OLD SOA ou even worst you might just be doing WebServices.

Netflix get it. All the components are build guided by core architecture principles and anti-fragility is on the heart of this components.


There are other stacks that are very promising like Akka and Twitter Stack(Finagle) but the main problem with AKKA is that the Operation part is payed and is not really close to what Netflix has to offer.  Besides that akka has another problem - The Programming model is Actors, dont get me wrong actors are great by is not a generic model for everything and does not work well with the service idea.

NetflixOSS gets operation right, is all designed to be Observable i mean in sense of Observability - like you can go there and see whats happening. There are logging, dynamic configuration, monitoring, drivers, load balancers and all sorts of mechanism your stack need it. There are so much emphases on operation not only on building thats why NetflixOSS is ready for the devops ERA because it acknowledge ops and take it into account and thats is something very different that you dont see in standard-  pre 2010 solutions for services.

The Architecture Principles

* Separation of Concerns
* Cloud Native
* Microservices
* Everything is broken and fails constantly
* De Normalized Data
* Chaos Engines
* DevOps: Run what you wrote, Anti-Fragility, Immutable Infrastructure, Failures are Opportunities to Learn, Blameless Incident Reviews
* Commitment to Continnous Improvement

The Main Architecture

This is the NetflixOSS Service architecture. You have your devices or service consumers that are connected to the internet and they talk with AWS Elastic Load Balancer and this is call the Zuul witch is just a poxy like HAproxy them will talk to services. Netflix makes difference from internal services and external services - external once they call edge services. All services are isolated and have they own databse and they dont access a central shared database.

The Core Middleware

Netflix has a stack for microservices and operations around it. The Key components are:

* Karyon -> The Nucleus of the microservices - It uses RxNetty as server
* Ribbon -> Java IPC driver to call other services - you can do rest calls with it and uses RxJava
* Eureka -> Discoverability solution Netflix built.
* Hystrix -> Resiliency, Circuit Baker, Timeouts solution -> Wrap app code that is danger with Commands.
* Turbine -> Visual Stream Aggregator for Hystrix - you can see failure and timeouts and circuit breakers at runtime
* Archaius -> Dynamic Configuration Manager for the JVM
* Governator -> Netflix uses Guice and here are the abstractions and wiring utilities.
* Zuul -> Proxy Server that does simple routing and security

For the Operations

* Asgard -> Kinda of Jenkins for the Cloud - Can create clusters, ASGs, ELBs
* Aminator -> Python solution to bake amazon AMI images
* Servo -> Monitoring solutions
* Ice -> AWS Cost Visualization and Monitoring
* SimianArmy -> Chaos Testing - Tear down data centers, instances, burn CPU
* Vector -> Monitoring JVM and servers at runtime

Next posts i will cover some of this solutions with code and examples - also will provide github code working :-) NetflixOSS is great but the documentation is not 100% and sometimes you really need debug and hack the code to understand whats going on. SpringCloud is the Netflix Stack(some very small part of it) with Spring not Guice and has some documentation.

Tech Posts with Code

* Microservices with NetflixOSS: Karyon, Ribbon and Eureka part 1 
* Microservices with NetflixOSS: Building and Running Eureka part 2
* Microservices with NetflixOSS: Karyon and Services part 3
* Microservices with NetflixOSS: Ribbon part 4

Cheers,
Diego Pacheco

Microservices Contracts: REST vs Native

Microservices Contracts: REST vs Native

Admin aaSunday, September 6, 2015

This is not a new discussion is very old. I remember back into the SOA days - always was something like REST VS SOAP. SOAP is dead and REST own but now is something different.

To be clear - I think REST is the only thing you should use when we talk about External consumers. Like and external API thats would be accessed by a mobile or website.

There are other scenarios like INTERNAL consumers. For this case you can consider using a NATIVE driver instead of REST. So whats is a NATIVE driver? Is just code into a language you are using - so could be Java, Scala, Clojure, Ruby, Go, whatever it does not matter. This idea is similar to the JDBC java driver you have java code to access the database.  So thats the real question when i have internal consumers for my microservices, should they talk to each other tought REST or native driver?

It really depends because both approach have PROS and CONS like everything in life - there are trade offs - but i consider REST in general a more same approach but lately some there are some tech evolution that are changing this game.

REST: The Good Parts

The biggest advantage of REST is interoperability - So you can code one microservice in java and the other one in C for instance and they will be able to talk with other by default. Second great advantage is the unified interface is always same way you dont have that with native clients or soap. Another great quality is abstraction because you dont have any dependency just HTTP and you are free to consume it using any library you want.

Native Drivers: The Good Parts

It`s way more simple to make a java or scala call rather than an HTTP call. Second you can have great advantage in sense of performance and being reactive. You can use RXJava or ReactiveStreams or Akka and gain lots of benefits beyond better performance and non-blocking io. Today you can even not do a remote call instead you can do a IPC call.

Both Have issues

REST for instance is more work for you because you will need to have a mapper to map exceptions to error codes, you will need to have classes to represent the objects you call and also will need make the calls to the service. Besides that you will need to make this for each service - thats the price for flexibility and interoperability. You still could have worst performance because its another layer of remote call and potentially blocking io.

Native drivers have problems as well - they are not a free lunch at all - first and biggest problem is coupling. Because you are calling CODE. Second you could potentially be into a Dependency HELL. Lets say you write down the native driver in scala, all libs you use in your driver will be loaded to your classpath and you might have conflicts like google guava or log4j or xml libraries and you will be tight to that libraries and versions and thats bad because it maybe make hard to you update libraries.

In the end of the day...

REST is best for independence but you can leverage performance from native drivers. You really need think case by case and see what makes more sense for you scenarios and even consider mixed approaches witch is totally fine as well.

Cheers,
Diego Pacheco

Agile is not only about management!

Agile is not only about management!

Admin aaSaturday, September 5, 2015

A long time ago a remember when agile on the early days was something driven by developers - pretty much by XP practitioners. Don`t get me wrong agile is about the customer, and its about making better software and of course mgmt is part of software but agile is not only about mgmt.

I`m really not sure when - maybe after PMI embracing Scrum and Jira rises as the ultimate agile tool(not for me :-) ) But today more and more a see less and less engineers going away from agile.  Maybe because they thing agile is about process, tools(jira) and practices(scrum) and thats a manager thing. To be clear agile is way more than scrum. I`m way more into Lean and Kanban than Scrum but i can`t deny i`m seeing this more and more on the market.

Whats the Side effects of this?

First of all - Software development is not only about code and a good coder is more than just CODE and to start we need start with principles - Make value for the customer. It`s odd but many developers are not familiar with the Agile Manifesto. Developers know what is? Yes for sure, do they know who to use the principles on they daily work? No - Not All - Do they care? No - lots of people dont care.

Part of the problem... 

May too much focus on PROCESS like SCRUM or even JIRA and too little focus on engineering practices like we have in XP: Collective Ownership, TDD, Simplicity, Continuous integration(more and more are replaced by branch's and feature branches) and Design the missing discipline(OO Design, FP Design, etc...).

People dont like to change

Most of time companies want add practices and not remove anything, companies very often dont unlearn process they just add more stuff. There are still tons of companies in Brazil with CMMI process / CMMI thinking - Yes most of they dont have the certifications - some have but the ideias are still around. So is easy to understand why developers would give up in all of this and just focus on the code.

However: Microservices are very hot right now

Surprisingly SOA is consider wrong. Thats non-sense because MSA is SOA. You need SOA principles todo right microservices. Microservices are one evolution of SOA. There are something else, microservices are about ISOLATION and INDEPENDENCE. So a team could be like a startup and should have they own database, they owen service interface they own way to work and tools and frameworks. Doing MSA you can have several benefits but to doing you need maturity and agile can help you alot with that.  Developers need Agile engineers practices most on XP todo proper microservices. How could you do proper microservices without thinking about testing and design? How could you do it property without doing Refactoring and adding value to the customer? So i think you need agile even with you are not a manager.

Cheers,
Diego Pacheco

Micro-Workers: A flavor or Microservices?

Micro-Workers: A flavor or Microservices?

Admin aaFriday, April 3, 2015

Microservices are about ISOLATION. I need point out some different aspects here, keep in mind the word: Microservices is compose by 2 words, micro, thats where you got the isolation, minimal business unit, great marriage with REST in sense of RESOURCE and several other things i mention on previous post.

There is another word call: service. This is where SOA come to play, there is lots of people talking BAD about SOA now a days, but they dont realize MSA is SOA.  Service is not a web service, so that word has more meaningful than people imagine.

SOA is about principles, its about great foundations that enable Service Orientation. That`s is an Architecture but its also a way to think also called SO(Service Oriented). Microservices make a lot of sense if you are coming down from a monolith its very DDD like if you pay attention.

SOA is about Contracts

In SOA we abstract implementations and leverage contracts, microservice is the same idea, but to have different contracts you need to have different services with different business units and different purposes. Contracts are everything. They are like interfaces or traits, allow us to hide implementation details and be able to change technology under the hood.  The service is an abstraction, there is not Service without abstractions. If you create severies that just expose tables is not a service is a web service(SOAP or REST/POX) and there is no business value on that. The REAL value is around having abstractions.

Microservices are about abstractions too

You still need to have abstractions with microservices the difference with SOA is that MSA whats a finer grained business instead a monolith with lots of things into the same service which makes lots and lots of sense. This make sense with DDD but remember DDD is Domain Driven, most likely for transaction systems.

There are other kinda of systems, business systems that are not Domain Driven by nature, they are what we call Data Driven, for this systems micro-services could be leaky definition.

Microservices is about small units but different services

You will have 3 different services with 3 different business implementations and most important 3 different contracts, this 3 different contracts is what made they different services. Someone could argue this is physiologically question. I would say no is not. Because it matters cause we shall do the contracts oriented to the consumers, Consumer Contract driven SOA, thats the right choise.

As Martin fowler said, smart and points and dumb pipes, like unix philosophy. And here ins this context this is very true. 

This previous microservice picture makes lots of sense with REST and DDD because of the very nature of being domain driven, but in data driven systems what happens?

Data Driven, workers rise!

In systems or part of the systems that are Data centric or Data Driven, you wont gonna have different services, you will have the same service because your contract most likely will be generic but what will change will be the data and data implementation but for the consumers there is no advantage whatsoever call individual services. So if the service is the same, i mean same contract, but the processing unit changes, a.k.a the workers, should not be a microworkers? Because we dont have want and wont have different services but different workers instead. For that scenario you wont have many discoverability issues since you dont have many services but you might have lots and lots of workers. 

People could still argue this is flavor of microservices, because the workers still would have the isolation properties of microservices. And each worker wont be a monolith. But again for SOA is the contract that matters not the implementation, them is slice different thing :-)

Cheers,

Diego Pacheco

SOA/MSA Backward Compatibility

SOA/MSA Backward Compatibility

Admin aaSaturday, December 20, 2014

One of the real game changing benefits of SOA / MSA(Microservices Architecture) is flexibility. Flexibility give you power todo things as you wish, in order to have flexibility you need have decoupled things but hold on a second, in a service oriented world everything is done via a contract and services are coupled to this contracts.

How could you still have flexibility if the contract changes you need rebuild all consumers and deal with the changes? Even worst than that - whats makes SOA different from webservices or procedures calls on the data base? (remember soa/msa is not about technology is about principles and design/arch.)

Service Contracts

Contracts are flat objects, in the end of the day is just data + other aspects around the service, like behavior, protocols, etc... Lets say you define the right contract, your business will change and that fine, but that change will affect other services or consumers? Maybe maybe not, but if you keep breaking your consumers you have a problem you will need coordination.

Coordination is bad because will kill you. You will endup with branches and releases that are tight and coupling, coupling is the root of all evil. Ultimately you want have different release cycles or even better you want have continuous delivery - speed is archive if you have isolation of each component - so we need independence - but how we got that independence?

Contract version

So you need explicit version you contract and start making differentiation around changes. You will have breaking changes and non-breaking changes. So what is a non-breaking change? Is something it not require the consumers to change they code - in other words is optional it wont break they code or logic.

So lets say you have a interface or a trait that represents the service, you will have classes for the input and output parameters, all that is part of the contract so you need to version this objects. The easiest thing todo is version the package or namespace.

For changes that will break the consumers, things like: add a required parameter, remove a output field or include an mandatory field or rename something you will break the consumers than you should create a new version. With this new version you can add you changes but you would still keep the old contract version.

Note on Deploy and Physical Architecture: Some folks use to have different services instance, thats leads to braching hell - IMHO is better have just one version of the service implementation and deal with the changes(backward compatibility) by code.

Multiples Contract Versions - Same Code

Thats the right thing todo if you want have flexibility with less complexity - CODE is better than branches. You will end up having to say explicit SOA/MSA Governance policies like: How many contract versions should we keep at he same time? 3,5,10? depends of your needs and how much you want to spent on backward compatibility.

This is one of the most important things around services. This is what makes possible to have localized changes. Now a dayz around microservices we are talking alot about isolation in sense of database, hardware and software, but if you dont have this kinda of mechanisms on the contract side of services you wont have the flexibility in sense of development and fast deploys and release oft

Service Internals - Dealing with BC

No matter what kind of architecture of design your service have it, you will need deal with backward compatibility.  The easy thing todo is keep the service implementation on the latest version and them migrate the old contract requests - responses to the current code.

So you would have an BC layer where you apply most of changes - most of times you be just a set of copy and past changes here and there, however sometimes this would not be enought so you might need have BC converters close to the service internal domain thats fine as long as you make that explicit maybe tought some interfaces/traits because this is a temporary code.

The nice thing about this is you can re-deploy just the implementation later and when every consumer migrated to the last version you can delete the old contract and code.

SOA Service Anatomy

SOA Service Anatomy

Admin aaFriday, December 19, 2014

Working as a consultant many times i raise the bar of the role architecture in great software. As solution engineers we often talk about software architecture. When we are working with SOA / MSA (Microservices architecture) we need realize that there is more than one architecture.

You could and most likely will have a middleware or container or bus or platform you do your business work but each *thing* needs to have its own architecture.

For SOA/MSA the citizen of first class are Services, so basically you work with Services and you just "see" services, in the end of the day what matters is raise the level of abstraction and leverage from that in business perspective.

Service Oriented Enterprise - SOE

SOA/MSA is not meant for a single system. The idea is that you will have your whole IT around services but not everything should be a service and thats is a design decision. I like to think about 2 metaphors todo this, 1 is a city map, 2 is a classification game.

So for the city map - you have all sorts of things into a city, hospitals, fireman, police department, marketplaces, tubes, cabs, roads, parks, etc... each of this things is a thing. So could be that every building is a service but you might have more than just buildings then you might have more than just services.

When we do SOA we should have a MAP and we should know what are the services and what they do and what they dont do.

We also should have SLA around the services, today we have plenty of tools to archive monitoring and control this SLAs.

This is important because is part of the service design, if you dont see the big picture you might make wrong decisions like put a Prison close to a primary school, very bad idea, this is the same as exposing a internal service directly to the web or coupling UI with a service database. All very bad ideas but often could happen - so a Map is very important part of your design.

Classification - What is a service what is not?

For me makes sense do a consumer driven SOA/MSA, so you need understand what are you consumer, what they need - so you can reuse by design - not by accident.  A very simple approach is move code to a service based on multiple consumers but be careful sometimes this could be wrong.

There is no standard classification schema but you can create your own, so what could be the options:
  - External Service - API
  - Internal Service
  - Internal API
  - DataService
  - UI APP
  - Mobile App
  - Legacy Application
  - Grammar / DSL
  - Integration Connector
  - Driver
And so on and on. The reason you might do that is because something does not fit when the notion of a service and it principles like mobile/ui app. Other times you make differentiation between service like internal vs external because than you can have different rules in sense of governance.

What is the Service Anatomy?

This is the service internal Architecture. Yes, every single service will have they own architecture and they could be very different. Some could be Request Driven most of times they are like that, other could be Batch or Analytic(Map reduce, etc...) and so on and on.  This pretty much breaks the idea that every service is the same thing often they are not.

Going deep on the microservice thing you might break you functionality per domain or per groups of users, this is awesome for operations and maintenance.  Microservices does not mean you need have less then 200 lines of code per service :-)

How to start things right?

Unfortunately everybody starts SOA wrong - by buying tools. You should first learn about software architecture, Service Orientation paradigm and them start doing proper SOE, how? Go do a map of your IT then you can start defining some rules per services.

SOA, Micro services and Isolation Evolution

SOA, Micro services and Isolation Evolution

Admin aaMonday, November 17, 2014

Amazon, twitter, linked in, eBay all this guys was dong webservices and evolve to soa and now they are at the next step the micro services era.

This is one of the most hot software architecture topics on the it industry right now. But how completely now new this is?  I would say for maybe your surprise, not so much. Microservices are SOA. IF microservices are soa whats the difference in the end of the day, well i gonna try to explain it here in this post. Short Answer: Is all about isolation, is all about have independence. Hold ON: SOA was about that as well :-) Yes thats true, i`m not saying soa is invalid of something like that, SOA was more focused on some architecture principles and big architecture concerns but MSA(Microservices Architecture) focus more on operational capabilities.

Monolithic SOA

For SOA granularity was never a explicit matter, and thats fine actually. Services can have different sizes and responsibilities and thats 100% ok. Right, so whats is the real problem them? In the end of the day people end up doing BIG services, thats is a problem in operation point of view.

So what you might want todo is break some of your big components into small ones, this does not hurt the SOA definition of a service and does change much how you use things but it gives you more decoupling and decoupling is always great. 

You are still doing soa and this sizes are not FIXED you could have smaller and buggers ones because it would really depends on your business needs. IF you go straight without thinking on the MSA thing you might have integration and data. latency issues not to mention federation so something could be bigger them other but the goal is to keep as small as possible.

In the way i see this SOA is bigger than micro services. You still have SO(Service Orientation - the main paradigm behind SOA) thats bigger than everything and micro services will focus on some granularity, isolation and operation capabilities. SO i see a perfect match between this two.

You might say i dont have this problems or I dont need this, right so tell me more about your release process, lets think about the following picture.

So in your release you have lots of coordination between components? All your components have the same version? If thats true you are in model (A). The problem with coordination is because in the end of the day means 2 things:
  1. You dont have real independence - It means you are coupled
  2. You dont understand what you are doing because you need threat everything as a single monolithic box - so it means you might have monolithic SOA.

On the second model, called (B) in my picture you can see different components with different schedules and different versions, this means you have independence and thats whats really what you want right? :-)

The Real Goal of SOA and MSA 

Business Value. Thtas it. In other words FLEXIBILITY, it means have the ability to work with different teams, different components, different business goals at the same time and fast and as consistent as possible.  So the SOA manifesto still valuable and you should still think about this.

http://www.soa-manifesto.org/

Why SOA Failed(Maybe) this time?

People just started doing things and have different names but in the end of the day they are talking about SOA. Like APIS, the whole internet talk about APIs most of them are SOA just with a different names and different granularity and concerns but still SOA.

The service part of SOA, not the architecture: There is a huge gap into the it industry for REAL and RIGHT software design and leadership or SOA Governance if you prefer name this way. Thats one thing - the second thing is operations, IT has evolved after DevOps era and now things are starting to evolve on this side

Is hard to operate something is monolithic like twitter monorail.  Micro service really try to fix this GAP.

The Magic around ISOLATION

So this is the KEY thing, thats the MAGIC. You want isolate your services so they not only have they own contract and implementation bit they have they own thread pool and database and even they own java VM or going beyond they own Docker container :-)

Why? Because if isolate things they are easy to reuse, they are easy to restart,you can have explicit fallback mechanisms you have threads isolation and if something happens you have precision localized problem in this case is easier todo fail over, load balancing, fault tolerance and operations in the end of the day.

You might not realize but you might need have TEAM isolation. This is what would enable you todo Cross Functional Teams. Isolation. Isolation Otherwise you will fall into coordination nightmare of meetings, releases, noise, communication breakdown and etc...

So with Team isolation them you can threat services as black boxes and this makes way easier to pay technical debts and also improve things under the hood.

Lets say you can do that on the service side, but always you gonna have DATA, Legacy Systems, Applications and other components that you might not control so how you can archive this isolation? Lets think about this.

Remember you can replace database for legacy or 3rd system or app. It really does not matter - what matters here is say something like there an LAYER i can`t get rid of it NOW and might take sometime todo this - thats fine.

So what you need todo is isolate that changes into another layer, so this will give you flexibility to handle they with less coupling.

Thats could be archived with DataServices, they are simple system strangles or engineering bridges. They are wrappers that will protect you from the LAYER or legacy you need to deal with it.

This does not mean you gonna have to deal with the changes, you will have to, but them this changes will be isolated into the black boxes and this will avoid to deal with them outside of the micro service.

This is great because you move things to the application side - so most likely you have better tools to deal with changes and do refactoring, versioning , backward compatibility, them legacy systems and databases.

There are things you need improve to get this right

1. SOA Governance Leadership Design process
2. Operations: They will need to deal with will more vms
3. Tooling: Create. deploy, configure and manage all this services
4. Federation and Latency: So some services might not be the same size as others.
5. This really might bring DevOps as a way to archive some of this work.

Evolution not Revolution

Evolution takes time. So you might take some years to make this right, and thats totally fine as long as you dont stop the world and keep delivery. Thats a challenge i know but as more as you go into the right SOA and micro service path and have more isolation less painful it will be.

Cheers,