The document outlines the differences between microservices and monolithic architecture, emphasizing microservices' advantages such as independent deployment and flexible scaling while noting potential challenges like complexity and data consistency. It details strategies for decomposing systems into microservices and addresses concerns related to security and session handling. The real-world application is illustrated through a case study at BestSecret, showcasing the successful use of Kafka for real-time data management.

2. About me
• Jesús María Villar Vázquez
• 11+ years of experience.
• Senior Backend Engineer at BestSecret.
• Java enthusiastic.
• Follow me in twitter! @geeksusma

3. Microservices vs Monolithic Architecture
• Microservices are a software trend with a high impact IT function, but digital
transformation of the entire business.
• Appears in 2010
• It’s has been successfully adopted by organizations like Netflix, Google,
Amazon, and others

4. What are Microservices?
• New way to create corporate applications
• Broken down into small and independent services whit his own stack.
• Those services, all together, they offer a whole functionality for your business.
• Are based in API’s

5. What are Microservices?

6. What are Monolithics?
• “Old school” SOA (prior to 2012) surely are following a monolithic
approach.
• Basically, if you need to deploy the whole system to update one service, you
have a Monolithic infrastructure there.
• If changes in your database affects to your whole infrastructure, that is
another symptom of having a monolithic approach.

7. What are Monolithics?

8. What are the main differences?
• A Monolithic application is built as a single unit (a database + a client side and a server side
application handling HTTP requests).
• Any update in any part of the unit, needs to deploy an updated version of the whole server-
side application.
• Microservice capabilities are expressed formally with business oriented APIs
• Dependencies between services and their consumers are minimized by applying the
principle of loose coupling.
• Any Microservice is independent one each other. If one of them is down, the others can
continue working safely 

9. Software development: Monolithics.
• There are some issues due to traditional approaches:
• Monolithic applications can evolve into a “big ball of mud”; where no single developer (or
group of developers) understands the application as a whole.
• Not very reusable.
• Scaling monolithic applications can often be a challenge.
• Deployment process often (but maybe not always) is quite hard.
• By definition monolithic applications are implemented using a single development stack (e.
g: J2EE or .NET), which can limit the availability of “the right tool for the job.”

10. Software development: Microservices.
• But in Microservices everything seems fine!:
• Services are encouraged to be small, built by a bunch of developers.
• They interfaces can be consumed and reused by other services and applications
without direct coupling through language bindings or shared libraries (e. g: using REST)
• Services exist as independent deployment artefacts and can be scaled independently
of other services. Deployment is less pain in the ass.
• This allows to the developers to use the appropriate development framework for the
task.Welcome to the real freedom!

11. Microservices: the trade off
• Sometimes the flexibility of managing a multitude of distributed services
becomes in complexity.
• How to detect services as potential reuse candidates.
• These services needs an extra effort to provide documentation, test consoles.
• Interdependencies between services need to be closely monitored.
• Downtime of services can have cascading downstream effects.The impact of this needs to
be proactively analysed.
• More issues not trivial to face as data consistency, session handling and security.

12. Microservices: How to move?
• The big challenge is deciding how to partition the system into Microservices.There are a number of
strategies that can help:
• Decompose by business capability and define services corresponding to business capabilities.
• Decompose by domain driven design subdomain.
• Decompose by verb or use case and define services that are responsible for particular actions. e.g. a Shipping Service that’s
responsible for shipping complete orders.
• Decompose by by nouns or resources by defining a service that is responsible for all operations on entities/resources of a
given type. e.g. an Account Service that is responsible for managing user accounts.
• Ideally, each service should have only a small set of responsibilities. (Uncle) Bob Martin talks about
designing classes using the Single Responsibility Principle (SRP).

13. Microservices: and what about Data
Consistency?
• In order to ensure loose coupling, each service has its own database (Saga Pattern).
• Maintaining data consistency between services is a challenge because 2 phase-
commit/distributed transactions is not an option for many applications.
• A service publishes an event when its data changes. Other services consume that
event and update their data.There are several ways of reliably updating data and
publishing events including Event Sourcing andTransaction LogTailing.
• Kafka 

14. Microservices: and what about security and
session handling?
• Thinks again in an Old School Backend, and imagine it has been evolved
from the current Monolithic architecture to Microservices.
• The example is clear, a customer log into the app, but the session needs to
be shared to don’t affect to the user experience.
• If every Microservice is independent one each other, what happens with the
customer’s session?

15. Microservices: and what about security and
session handling?
• There are two different ways to fix the issue regarding the session handling:
• Sharing cookies between the auth server(s) and application server(s)
• We'll address this challenge by running all servers under one domain and proxying to the various servers.
• On one server on one domain, this was not an issue.
• With multiple servers on multiple domains, it is.
• Sharing a session store across server(s)
• Consider the usage of redis to follow this approach.
• Or Spring Session + Spring Cache
• Or a very easy solution could be memcached with some token strategy

16. Microservices: A real case in BestSecret
• The PLM case (Product Lifecycle Management)
• Two Stacks:
• First is .net:They are the responsible of taking care about, when a new product arrives, or maybe
an existing one has been changed (title, pictures, description, prices and so on) to make him
more attractive.
• Second is Java:The backend used by the webShop and Mobile devices needs to be updated
about, when a product is new, has been changed or maybe un-approved.
• Both Stacks are not sharing the same database instance (evey one use his own instance)

17. Microservices: A real case in BestSecret
• The PLM case (Product Lifecycle Management)
• What’s was the problem?
• Sometime ago, the products were updated/created in the ”webShop” side through a pretty
obsolete CronJobs:
• Needs a very cautious downtime to don’t impact in the UX
• Sometimes, the database could get blocked by an endless locks.
• Very long transactions, not quite nice.
• Needs some kind of coordination/notification between teams.
• Not real time.

18. Microservices: A real case in BestSecret
• The PLM case (Product Lifecycle Management)
• How it has been solved ?
• If we have to different stacks, totally independent one each other, why do we have to create
constraints between them?
• Let’s use Kafka!
• Kafka is very useful for building real time data pipelines.
• So the ”.net side” only need to publish changes when a change is requested.
• And the “java side” only need to be subscribed to those changes to fire actions in the background.

19. Microservices: let’s time to play!

20. Microservices: let’s time to play!
• Two MicroServices:
• Two differentTomcats (in port 8080 and 8090)
• Developed with SpringBoot as Rest Controllers
• First is to do some login and updating some data
• Secondly is to check if the token is valid and to delete the token afterwards.
• A Shared Cache:
• Using Memcached as a SO service

21. Microservices: let’s time to play!
• The idea is to see how the data added/updated in the cache is visible to
every Microservice!.

22. If you wanna have more info…
• https://www.mulesoft.com/resources/api/microservices-vs-monolithic
• https://www.mulesoft.com/resources/api/what-are-microservices
• http://microservices.io/patterns/microservices.html
• https://sequoia.makes.software/session-management-with-microservices/
• https://www.youtube.com/watch?v=aWI7iU36qv0

23. Working at BestSecret - Granada
• What is BestSecret? (http://www.bestsecret.com)
• Founded in 2007.
• Fashion company focused in e-commerce. 15M items, 35K ships per day to all Europe
• Headquarter in Munich.
• +350M€ Yearly Gross Revenue. Goal in 2020: 700M€.
• Local Shops in DE, AT, CH, SE, FR & UK, soon NL, DK & NO.
• BestSecret Granada.
• Technical Office opened in Mid 2015.
• 30 Engineers full time dedication in Agile teams. Soon 45.
• Main Technologies: Java, Mobile and .NET.

24. Working at BestSecret - Granada
• What are we looking for?
• Full Stacks developers/engineers.
• Fluent English.
• 3+ years of proven experience with Java.
• Knowledge about testing (Junit, Itest, End-to-end) automation and continous
integration.

25. Working at BestSecret - Granada
• What we offer?
• Permanent role inmediately.
• Salary over sector average.
• Training. Conferences, travels and many more.
• Brand new equipment, you’ll never be out of fashion.
• StartUp atmosphere

26. Questions?