Micro Services
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 11 | |
| Number of Parts | 59 | |
| Author | ||
| License | CC Attribution - NonCommercial 2.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/19636 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Open sourceFreewareWeb serviceWeb serviceBitType theoryOrbitKnowledge-based systemsInheritance (object-oriented programming)XMLUMLLecture/Conference
01:40
SoftwareSystem programmingSound effectFunction (mathematics)Run time (program lifecycle phase)Physical systemSoftwareWeb serviceMultiplication signAnalytic setCodeMereologyLibrary (computing)Modulare ProgrammierungFunctional (mathematics)Component-based software engineeringInformationRun time (program lifecycle phase)Moment (mathematics)GradientSoftware maintenanceMathematicsComplete metric spaceContext awarenessAreaProjective planeState of matterEnterprise architectureJSONXMLLecture/Conference
04:52
SoftwareSystem programmingSound effectSoftware developerFunction (mathematics)Run time (program lifecycle phase)Software frameworkWeb serviceData structureSlide ruleBitContent (media)MereologyPresentation of a groupMultiplication signWritingRight anglePoint (geometry)Software frameworkView (database)Hazard (2005 film)AdditionJSONXMLLecture/Conference
05:49
Selectivity (electronic)Kernel (computing)Functional (mathematics)Table (information)Software frameworkDistribution (mathematics)Process (computing)MereologyRight angleArchitectureRadical (chemistry)Java appletServer (computing)Lecture/Conference
06:51
Functional (mathematics)Modul <Datentyp>Reduction of orderMereologyMereologyPublic domainDifferent (Kate Ryan album)Functional (mathematics)ArchitectureTelecommunicationCartesian coordinate systemMaxima and minimaVertex (graph theory)Arithmetic meanSoftware developerSoftwareWeb serviceJSONXMLLecture/Conference
08:49
Service-oriented architecturePhysical systemDifferent (Kate Ryan album)Integrated development environmentCartesian coordinate systemCentralizer and normalizerWeb serviceArchitectureLogicMereologyGame controllerSoftwareFunctional (mathematics)View (database)Public domainProgram flowchartLecture/Conference
09:53
Web serviceDecision tree learningProduct (business)Coma BerenicesFunctional (mathematics)Single-precision floating-point formatDatabaseWeb serviceMereologyFlow separationCartesian coordinate systemBitLine (geometry)Message passingRepetitionProduct (business)Standard deviationMeta elementWeb 2.0Lecture/ConferenceComputer animation
10:50
Decision tree learningProduct (business)Product (business)MereologyLibrary catalogView (database)Electronic mailing listCartesian coordinate systemSoftware developerSystem administratorDatabaseWeb browserCASE <Informatik>Web serviceSoftware testingGoodness of fitPublic domainContext awarenessDigital rights managementDecision tree learningDifferent (Kate Ryan album)Complete metric spaceMathematicsoutputClient (computing)Projective planeSummierbarkeitDistortion (mathematics)Scaling (geometry)Data storage deviceReal-time operating systemScalabilityLibrary (computing)FamilySubject indexingPoint (geometry)Interface (computing)Group actionInheritance (object-oriented programming)Multiplication signBitBusiness objectFunctional (mathematics)Component-based software engineeringMedical imagingUniform resource locatorAreaDatabase transactionResultantNormal (geometry)Video gamePatch (Unix)Term (mathematics)LogicPopulation density1 (number)Student's t-testArithmetic progressionComplex (psychology)File formatWeb applicationReplication (computing)Server (computing)Form (programming)Image registrationLecture/ConferenceComputer animation
19:12
Product (business)Decision tree learningView (database)Different (Kate Ryan album)MereologyAreaData storage deviceState of matterRead-only memoryMiniDiscoutputFunction (mathematics)Independence (probability theory)Order (biology)CASE <Informatik>Software testingMenu (computing)ArchitectureDatabaseProduct (business)Line (geometry)Digital rights managementFlow separationComputer iconNP-hardOverlay-NetzDatabase transactionPerturbation theoryComputer animationLecture/Conference
21:41
Web servicePopulation densityDependent and independent variablesWeb serviceMultiplication signReal numberGoodness of fitCovering spaceComponent-based software engineeringDisk read-and-write headMoment (mathematics)Instance (computer science)Latent heatComputer animationLecture/Conference
23:23
Web serviceRootPublic domainCodeLibrary (computing)Flow separationSoftware repositoryFlow separationWeb serviceWater vaporHill differential equationPhysical lawSoftwareMultiplication signForcing (mathematics)Component-based software engineeringComputer animation
24:17
Business objectRevision controlCodeLibrary (computing)Functional (mathematics)AuthorizationComponent-based software engineeringProjective planePhysical systemPublic domainLecture/Conference
25:26
Web serviceRootPublic domainCodeLibrary (computing)Flow separationSoftware repositoryObject modelOrder (biology)Theory of relativityData typeCausalitySocial classView (database)Product (business)Java appletEndliche ModelltheorieObject (grammar)Row (database)Electronic mailing listWeb servicePhysical systemComputer animation
26:19
ImplementationProcess (computing)Integrated development environmentWeb serviceMacro (computer science)DatabaseAxiom of choiceFreewareSoftware frameworkFormal languageFunctional (mathematics)Module (mathematics)Rule of inferenceServer (computing)Medical imagingCASE <Informatik>NumberEnterprise architectureJava appletImplementationServer (computing)Multiplication signFormal languageCodeBuildingKey (cryptography)Projective planeCartesian coordinate systemProcess (computing)SynchronizationDisk read-and-write headPrice indexLecture/ConferenceXML
27:35
ImplementationWeb serviceCartesian coordinate systemAxiom of choiceComplex (psychology)Content (media)Sound effectStrategy gameImplementationMultiplication signPhysical systemMereologyView (database)DatabaseConfiguration spaceFunctional (mathematics)Formal languageSoftware frameworkSpring (hydrology)BootingMultiplicationDemonWeb 2.0Different (Kate Ryan album)Stack (abstract data type)Heegaard splittingLecture/Conference
30:07
Software frameworkJava appletSpring (hydrology)BootingVertex (graph theory)String (computer science)TelecommunicationCartesian coordinate systemSpring (hydrology)Process (computing)Server (computing)Uniform resource locatorSoftware frameworkJava appletWeb serviceConfiguration spaceComputer fileParameter (computer programming)Bookmark (World Wide Web)Drop (liquid)Software developerDatabaseFormal languageRow (database)Multiplication signVertex (graph theory)SummierbarkeitBounded variationVapor barrierFrame problemComputer animationLecture/Conference
32:24
DatabaseReading (process)Web serviceView (database)Replication (computing)Link (knot theory)Key (cryptography)System callDatabase normalizationBlogDatabaseSemantics (computer science)ArchitectureRelational databaseWeb serviceXML
33:19
Web serviceDifferent (Kate Ryan album)Database normalizationMultiplication signCellular automatonRelational databaseMereologyRead-only memoryDatabaseAuditory maskingGoodness of fitMedical imagingLine (geometry)View (database)System callData storage deviceLink (knot theory)OracleLecture/Conference
35:20
Cross-site scriptingCommitment schemeMenu (computing)Web pageGraphical user interfaceWeb browserClient (computing)GUI widgetWeb serviceWeb pageWeb serviceGoodness of fitCentralizer and normalizerACIDCartesian coordinate systemMereologyXML
36:20
Web serviceSingle-precision floating-point formatGoodness of fitBit ratePresentation of a groupQuery languageDifferent (Kate Ryan album)Web pageOpen sourceLink (knot theory)Information overloadMereologyScripting languageClient (computing)Structural loadView (database)Graphical user interfaceSystem callHeegaard splittingLecture/Conference
38:01
Information securityIdentity managementPhysical systemModule (mathematics)Web serviceDistribution (mathematics)LoginContext awarenessDigital rights managementElectronic signatureHTTP cookieShared memoryPublic domainIndependence (probability theory)CryptographyInformation securityPublic domainHTTP cookieMereologyCommitment schemeWeb serviceContext awarenessSlide ruleIntegrated development environmentIdentity managementDigital rights managementLoginLevel (video gaming)Electronic signature2 (number)Multiplication signSystem administratorCartesian coordinate systemPhysical systemSign (mathematics)Right angleCommunications protocolFormal verificationXMLComputer animation
40:08
Web serviceMereologyCommunications protocolProduct (business)LoginGame controllerNumberLecture/Conference
41:00
Software testingJava appletDigital rights managementSanitary sewerExtension (kinesiology)Group actionServer (computing)LoginWorld Wide Web ConsortiumResource allocationTelecommunicationAxiom of choiceWeb servicePlastikkarteInterface (computing)AbstractionComputing platformWeb serviceStress (mechanics)MereologySystem administratorFraction (mathematics)Axiom of choiceTelecommunicationBookmark (World Wide Web)Interface (computing)Formal languageRepresentational state transferServer (computing)ImplementationGroup actionCASE <Informatik>AuthorizationXML
42:24
TelecommunicationEvent horizonStructural loadError messageData recoveryDistribution (mathematics)TelecommunicationWeb serviceLogicMultiplication signAreaCausalityInformation securityEnterprise architectureAsynchronous Transfer ModeConnected spacePhysical systemGroup actionRepetitionStructural loadException handlingLecture/ConferenceXMLComputer animation
43:55
TelecommunicationDistribution (mathematics)Event horizonStructural loadData recoveryError messagePhysical systemProcess (computing)Exception handlingWordExtension (kinesiology)QuicksortTelecommunicationWeb serviceRemote procedure callInternetworkingRevision controlOrder (biology)Game controllerSoftware testingPoint (geometry)Unit testingLecture/ConferenceXML
45:02
Web serviceDisintegrationPersonal digital assistantSoftware testingExecution unitWordPoint (geometry)Web serviceLetterpress printingComponent-based software engineeringUnit testingSoftware testingCASE <Informatik>INTEGRALPhysical systemExecution unitCodeServer (computing)XML
45:55
AutomationStandard deviationScripting languageConfiguration spaceDigital rights managementComputing platformWeb servicePhysical systemRootComputer-generated imageryInstallation artWeb serviceSoftware testingInternet service providerUniform resource locatorPhysical systemMedical imagingOcean currentAuthenticationVirtual machineComplete metric spaceCartesian coordinate systemRoutingMathematicsScripting languageAutomationLecture/ConferenceJSONXML
47:34
BootingMetric systemLoginScripting languageWeb serviceMedical imagingCausalityMetric systemReal-time operating systemSlide ruleJava appletResultantRepresentational state transferMultiplication signReduction of orderLevel (video gaming)NumberLecture/ConferenceJSONXML
48:41
Programming paradigmWeb serviceOperations researchChaos (cosmogony)Computer networkComplex (psychology)Cartesian coordinate systemComputing platformProgramming paradigmProjective planeWeb serviceWeb 2.0CodeInterface (computing)MereologyPoint (geometry)Latent heatIdentifiabilityPhysical systemDigital rights managementMobile appDifferent (Kate Ryan album)Self-organizationSystem callSelectivity (electronic)Asynchronous Transfer ModeMobile WebOperator (mathematics)Functional (mathematics)Right angleProduct (business)ResultantRandomizationWeb pageUniverse (mathematics)Graph coloringPerspective (visual)CausalityQuicksortExpert systemModule (mathematics)Line (geometry)Standard deviationLecture/ConferenceJSONXML
54:34
ConsistencyAnalytic setVideo gameProjective planeMereologyCASE <Informatik>MathematicsArithmetic meanComplete metric spaceCartesian coordinate systemIntegrated development environmentDatabaseWeb serviceNoise (electronics)Client (computing)Server (computing)Execution unitDifferent (Kate Ryan album)Endliche ModelltheorieLogicVector spaceAmenable groupVotingRepresentational state transferGoodness of fitRepresentation (politics)Point (geometry)View (database)Physical systemGame theoryWeb browserModule (mathematics)Data storage deviceBuildingReal numberStack (abstract data type)Greatest elementLecture/Conference
59:47
Computer animation
Transcript: English(auto-generated)
00:15
Yeah, I'd stop this because I think I won't get sick today
00:24
Okay, so welcome you to my favorite topic it's micro services Maybe she will listen here Is I micro service is a topic which is
00:47
Many conferences and even in some No who can take this one and oh It has a battery so
01:02
Too much live in it So micro services is a topic Which is evolving over lasts lasts Year maybe and become an more and more
01:22
Visibility and there's no clear definition what micro services are so what I am sure what I showing you Are a bit of opinions of other people, but also a lot of my opinions in it So don't take this as micro service, but them get my picture with this
01:41
To start talking about micro service has to start By talking and explaining a monolithic software architecture, so What's bad on monolithic software I I often have seen very large systems where where all the software's you're working together, and you have one big deployment and
02:05
After time it is very hard to work with this this is I think the one of the biggest problems currently in maintenance and and you reuse of software modules What's hard with a monolith it's hard to test it so
02:25
You can't isolate pieces isolate pieces to test them It's hard to refactor because you always Kick something other down if you change pieces Because you cannot see the
02:43
Changes to the system if you if you do something with it Especially when you come to bigger teams or small teams But a few of them in bigger environments, and you don't have you have shared code So you don't have a code ownership, then it's very hard to work together on a monolith
03:07
And a lot of software Software knowledge is about reusability and We often see a re-usage on technical parts, so it's easy to
03:21
reuse the transport library or network stack or REST or JSON libraries things like that, but it's very hard to reuse functionality in software It's not often that I that I saw the re-usage of functional components so this is
03:40
Especially I think because in a monolith the the things are very tied together So if you try to take functionality out of the monolith and put it in another context Then you lose too much context information or tongue or dependencies, and so it's hard to reduce functionality And especially in runtime. It's very hard with a monolith because you have the same
04:05
Runtime dependencies for for the complete system so on performance and scaling you always have to scale up the whole of the system and You always have to deploy the complete system at all and with big systems this becomes some very very hard
04:24
nearly impossible in some some things so in big enterprises you often see the problem that the Project at the start is very fast and then At the end you only are able to do one release a year or one release Or two years or things like that because it's not possible to to bring the monolith software in a in a
04:46
continent state More often I Think this was the last time on a slide as 25 slides so I will speed up a bit I maybe it's a bit too much content if I'm getting too fast then please raise up your hands tell some questions, and we can
05:07
Even yeah, if not follow the the presentation on this part and talk about it So I'm not not fixed to do it in a fast way
05:23
But how to avoid a monolith it's not easy to say what makes software monolithic Because It's nothing about technology so even if I if I show you a nice Microservice framework, and you are doing everything right from technical point of view you may end up with something
05:42
distributed and everything's called talking with rest to each other, but Yeah, you end up. Maybe with the same thing than before but with with additional hazard or non distribution, so The first part of my talk is about how to design the architecture to get
06:04
vertical the vertical architecture following the functionality, so If you think you you have a monolith for your eyes take a take a very good look on it And and show what it is because even if you have
06:21
Maybe a big JBOS with Java server faces and things like that and Java portal or things like that Even then it may be that Inside of it. There is a very good vertical structure, so it is not not only on the on the technical side and Yeah on the other side as I said don't trust in using cool
06:45
Microsoft's frameworks to get the right architecture so think vertical start from the requirements engineering part to To see what are your domain parts? What are the the columns to to divide the application in and then very very clearly?
07:06
divide them and Yet to give give the developers no chance to bring different functionalities together on an easy way Then do the maximum to reduce
07:21
dependencies between those parts of course So on every dependency you try you would like to introduce Yeah, take the work and do it stood another way, and it's it's much work not to get dependencies maybe Sometimes you have to do two or three days work only to avoid to get a new dependency in it
07:44
but this maybe were maybe You will get an outcome of it some month later. I think One very very essential thing is that on on bigger applications and bigger teams you have to You have to build end-to-end teams functional on the whole of the whole application
08:06
so if you Divide the team and the development in different in different horizontal Teams then the architecture will always follow this and you will not be able to make a
08:21
Vertical functional design on it because the the communication and team will always tend or lead In this way to it that the dependencies that the dependencies and software will follow The teaming and so you will get an horizontal architecture So I've talked a bit about vertical horizontal
08:43
What does it mean of this in a classical approach you have maybe this simple architecture and so you I layer you have services and your persistence layer with it and As application grows and this is also the the difference between the the older though our approach and the Microsoft approach
09:05
If the the system grows then you mostly get this pyramid Thing pyramid Architecture where you have a central UI layer Different services and on the persistent services or logic services. It's more and more split it
09:24
But with this you are not able to reuse part of it And you will end up it was a with one software system and it Not not dividable because You have the UI layer and you cannot control how functionality of one domain will use the functionality of another domain
09:48
my view of a microservice architecture would Look like this that you have for every functionality a cleanly designed column where you split up on on every vertical on every horizontal
10:07
Layer you split up for the microservice columns, so In the database layer and the service layer and especially in your I layer You may split up the application in single in single part part applications, which are distributed distributed youtubal
10:25
changeable and Developable Separately to make this a little bit more practical. I have
10:41
Made a meta an example for for web shop so imagine you have a standard web shop like every one of us knows it so it was a part of product catalog and Product list view product detail view and things like that. This is a very good example
11:01
To show how it is dividable in in different columns, and maybe I have to out of the view In an old way one would make one application for all of them maybe Two applications one for the for the end-user and one for administration or things like that and
11:28
In a somewhat more modern and Yeah, software developer would like to get modernization in it may try to extract the business logic area and
11:43
domain objects for all of those and try to split it with libraries or things like that to get it a bit more moderate modularized, but I think the right approach is to divide every functional part in a very own column
12:02
with as few With fewer dependencies to each other as possible So I will go through it So for look in for example, and you should bring things like look in
12:20
in a single component where you have to look in a service and a data store for look in for example, and The data store is not the same like the other Areas have but the data store is simply for look in so for registration and user
12:40
Permissions maybe so that you can do look in part even it's think about think about that They look in is divided that you can divide the look in in more columns and then this this Application part should also serve the UI for the administration stuff and for the end-user stuff
13:03
So with this first column, it's very easy On a development side so you will end up with a small web application Which just enables you to see log in form for example to log in with it and then get redirected to? next to another to another part
13:22
so The other parts don't have to look in logic by themselves don't provide it But if you come to another side, then they will see oh no It's not login redirect to the first to the first service and don't handle them themself From the browser view point of view
13:43
It's essential not to follow an Portal like approach where you have one vertex one horizontal layer in between which ties everything together, so if you Do it hardline this architecture, then the browser in the first case comes
14:03
to this service on maybe in a completely different Domain, so this may be look in dot shop.com for example and this Are on our different subdomains of course it's possible I mean in a second step to bring the patch in front of it or things like that to mix it together
14:24
again So let's say the user has looked in then it comes maybe to maybe it's a administrator to management area with a product catalog in this part is vertical designed and
14:42
independent of the of the other parts so It is for example the the product Yeah, edit forms for for product or import forms or things like that import functionality to create all the products and as you see
15:00
The microservice approach enables you to give every Functional part every column its own database its own approach and storing data So in this part, maybe you decide to say okay product catalog. This is a relational Approach, so I use a postgres database and you store it in the postgres database
15:25
Then after adding product The next you want to do is browse them search them do the listings of them and this is a You can say it's the same so I will do it in one component but if you take a closer look on it, it's a completely different thing because
15:45
the The user side so the end users are different ones the scale ability is a completely different So maybe you have two or three people adding products But I hope some million customers I'm using it so you have completely different scaling approach scaling requirements and
16:05
the Requirements for your database are also very different. So here you would like to have a transaction and absolutely safe data handling and things like that and everything you would like to have here is very fast results very fast searching and
16:24
But you don't need any normalization here so it can be completely denormalized So maybe an elastic search another document-oriented search index database would be perfectly fit here So why it makes it up in one application if you can divide it you simply need an
16:43
interface between those services to give the data to the next one and Store it in in this format. So the the end user Will completely use this Column and this data store and does not have anything to do with your postgres database And this is read-only so we can reap
17:05
Repletion Replicated and Your store it ship it and even you have Here, maybe you have a real time dependencies because on safe you wanted safe here You don't have retail and dependencies in most cases
17:21
So maybe it is enough to push changes in product database to the to the clients So or to the to the workers here every hour or things like that. So you can handle it in a very different way and This column is much smaller. So we have a simple application
17:42
much simpler if it has this complexity with it and you can redeploy this part for example, and as you like bring down the server redeploy it have one our downtime for product catalog if your product managers don't care without Changing the uptime of this column. So if in the dividing brings you a lot
18:06
Okay, next part. Let's see the product details. So you have your lists you click on a product and you will see the detail for example in this and this image I Say okay the product data
18:21
Talks with this over an interface and get the product data from there So all products are here and column doesn't happen have its own database you always also could have this decided otherwise and Yes, you you've divided especially in the UI so you maybe you your searches are more frequently used than your
18:46
Product details or you you have your product detail service also in other functional contexts So then you can handle both very independent of each other Okay, come to the next part. So a shopping cart is a very interesting example because
19:04
it's it's also very yeah, very split from the rest because It has its own UI mostly so if you are on the shopping cart detail view, it's it's different from the other views and
19:21
It has very different Storage requirements again. So maybe you have the shopping cart in a session based you can Store it on serve and memcached or something like that. Of course other possibilities would also be there and You can handle it independent of this part. So this is read-only
19:43
Staying read-only this data and this is a session based storage Here on the UI is a very interesting case to bring them both together because I said every Column should serve their own UI too. So not one UI, but of course when I search
20:04
Products and I'm in details. I always want to see that I have 42 items in my shopping cart So I need an Yeah, it should make in a line here. So I need another way To interact in the UI. There are different
20:23
Solutions for that. So also would be possible to say. Oh, no, I'm not that hard liner So in this UIs I do call to the service and bring bring it in there or it's possible to serve Even the I can and maybe an overlay menu or things like that from this column as
20:42
in UI fragments or Smaller hot ml part or things like that and let this UI Catch it from the other column to bring it in So these are very similar examples when I finish my shopping cart, I can Redirect and check out area with with own dialogues
21:02
Which is independent of it other is it just needs this data the the end state of this data as an input and has an output which Has to be stored in any transactional safe database, for example, so an order management at the end, for example
21:21
So this should give you an idea what what I mean when I say, okay Introduce a very very hard functional followed Separation so this is from a architectural part the next part is more more technical
21:44
Even when I said that there is no real definition on microservices, there is a very good talk from James Lewis Which you can see online There he he was talking about microservices and the most papers or
22:01
Talks are referencing him Because he yes said something some some very simple things But they are very ever essential I think so I did not try to bring a bring no definition here So Microsoft is has to be small with a single responsibility
22:21
So make it very small that it only does one thing at one time What small small is it when it is small enough to fit in your head at the time So is it bigger to understand it in in one moment? Then it's too big then you have to split it up Of course, it's somewhat soft definition, but it's the only definition
22:45
possible I think on being small and Small enough that you are able to rewrite it Instead of maintaining it for a very very long time so if you Design such a column very small then it may be more easy
23:05
to replace it with a new software component and Because it's small and you have very few dependencies to neighbor columns Because of this it is easy to to know the specifications of it and really do a replacement on it
23:28
It's hard to it's easy to get an idea of a separation, but it's hard to enforce that this separation Will live for a long time
23:42
So if you see Conway's law and things like that then you see that the yeah the water always follows the the easiest way it always is Yeah, always It's going from from hills to ground So you have to do some things to enforce it that to make it hard to
24:04
Bring in new dependencies one of this Is is that you have to make every? Service an own software component, so it has to be in its own Version control system with its own build system buildable
24:23
Totally independent of each other and if you have dependency or come coat with other components Then you should treat other components as external projects not as oh This is this is my project one does my project two I can make
24:41
My comments library and put all shit in this then you yeah, then you Already I'm building a monolith so the only code I think which are he sings and I agree Which can be
25:02
Come code and come libraries is infrastructure code, so maybe networking code Maybe authorization code things like that so no functional code Yes Always or often a question how to treat domain objects so when I see the domain driven design
25:24
ideas and things like that then it's oh, it's often I've often seen that people are making a very very big object model and class model of All of their objects and relations with them together So isn't there worth in reusing this in all of your columns. I say no because
25:46
Every column would have its own view on the data So there is not not the true object model for all of your system So let's see for example An order item record so a product
26:01
The the data type of the product for the list and the detail view is very different from the data I know I have to have in the Order service at the end for example, so there is no worth in having one Java class representing this and this
26:21
Because in one case I need very much data and images and things like that in the other case only the number maybe and the price so How to implement it? I'm I have a Java background. So mostly Java background. So a lot of
26:42
things may especially true for Java, but in other languages also, but as you see the Java world and they were Very bad with was this idea for a long time. So building monolith monoliths with Java is the easiest Thing I think and other language are doing it a bit better since it's a lot of time
27:03
but you also in PHP for example when I deploy all my PHP code together in one Apache it ends also the same thing like is if I had all the Java code in one jpos so the key idea to think different Someone laughing he was in a project with me
27:24
The Key thing in implementation is forget all about application servers So when we saw Java we had application servers with the idea to deploy everything in this container, but we mostly saw that the
27:42
that the Container configuration was done very specialized. So we end up in multiple container deployments For every application one of this so if you does as a truth and try to bring The complexity of the container to minimize the complexity of the container and bring it
28:04
Ship it together with application. So the application the container is part of the application. It's the same like And Unix teams do for for a long time. So bring up one demon and Don't care from the outside view and deployment view
28:21
About the implementation language Just the right stack. As I said, you have to freedom for every column to choose. What's what's You what the requirements are saying you You can not only Use this for the database choice, but for the for all of the application
28:43
So if you need a very reactive system, yeah with much as I'm gonna see maybe it's different Technology choice then then a simple web UI Where or from things like that so you can choose for everything a completely different stack
29:02
but of course be careful because It would be hard to train every person to know every stack And It's very there are two strategies. I've read about How to decide when to bring up a new service
29:22
I'm a big favorite of of in the first step Try to bring every functionality in its own service And if you say if you see that the service is too small in the next step Maybe merge it in another service because it's much more easy to Merge multiple services together to one instead of splitting a big monolith afterwards
29:46
Which is absolutely impossible. So even if you Let your small surface grow and think okay, let it grow and split it let it grow and refactored I don't think that is that it that this would be possible on the other side I can
30:05
recommend three frameworks and spring boot is a Somewhat younger framework from the spring community or from spring company to start spring applications
30:21
Themselves so in the in Java instead of an application Location server you will always end up with a fat jar Where you have all your dependencies in the jar and start the service by doing Java minus jar The jar and maybe configuration file as argument So everything you have to do is ship one file have one configuration file to bring the service up
30:45
my favorite framework because I'm not so So familiar with spring I think spring is nice, but it's never be mine never become mine My favorite is drop wizard was Is
31:01
Coming from JAMA and there's one very active developer who is Pushing it and it's a very simple framework. So if you would start with a with your Own Java main and add everything you need for doing rest for doing configuration and you will do it very smart
31:21
Then it would be maybe equal to that what rock with others, but you don't have to do it yourself You can easily use drop is it food? Martin lie had Talked about drop was out before me. So if you're interested in it, you also can show the recordings afterwards
31:44
Vertex is a very No, it's not very new. It's there for some time now, but it's a very different approach to make to to think about up and As in journals communication and Vertex also has a possibility to create fat jars out of your services and to start them and alone in other
32:09
Languages there are also a lot of ways to simply write a deem because it's not a Not a new thing to write one simple service So I don't have have brought them up here. I started I already said something to the database
32:27
What should I do how to should I implement the database The essential is that you should try to give every column its own database for
32:41
semantical reasons architectural reasons and for scaling reasons Especially My experience is that in the question should I use the no SQL or not? No, it's called database here or Asian relational database here and I always could not say
33:02
I this is better or this is better. I don't want to lose this one or the other and With microservices, it's mostly very easy because for one service It's mostly very clear to say which is a better approach Mostly it's not my nose girl approach but
33:21
You don't lose anything because in this on this parts where I want to use a relational database you can use it There are you need some strategies because of sometimes one part of course needs data from another part There are some ideas on it
33:44
So first have the clear idea, but Don't be a hardliner So the easiest way is of course to and the cleanest way is of course to make a make call Maybe rest call to a different service and get the data but there but
34:00
To optimize and to optimize this don't fear about redundant data So fetch your data stored in your own database there for next time or we fetch it if you if you think think it's it's not guilty anymore and Don't fear the data redundancy It's also possible to
34:22
To replicate it to pull it by feeds for example and always Yeah, bring the data you you need a new database There are also some solutions you should not try to use but which are
34:41
Yeah short solutions which may be may be good for you One simple thing is if your relational database then use one database for different services But give every service its own schema then you can Make read-only views for example to access data from other schemas, then it's not that clear
35:04
But it's also a good good solution or Like an oracle or thing like that you can also use database tech database techniques like database link or things like that to Get the data of other data stores on the UI. It's a very complicated part
35:25
And I think there are not not so much good known solutions until now The essential thing is make every service really independent of in another one So don't let one service serve the layout and the the menus and things like that and another service on the content
35:47
So not a portal idea, but make every service independent Serving the full page if you directly navigate to this service to this subdomain or things like that then you get this this
36:02
Then you get the full application To not have to of course you don't want to do styling and layouting 100% redundant so maybe it's a Good thing to have an central asset service, which serves come come parts for all of them
36:24
It's also a good good thinkable to yeah to deliver the central parts from every service themself and let them Be merged on the client side by as in corners JavaScript I think that
36:40
if you have single page apps It's I think it fits good in this in this idea But then of course you have to make in full rate and full redirect full page load on every service border to another one so
37:01
In In one service it's not a problem to make a single page Yet one thing I mentioned with the shopping cart it's the idea when one view is not
37:21
100% split to the two different services you always have views where the user has to see data from different services then You have two solutions Call rest service and fetch the data and don't be a hardliner and simply show the data there or the other
37:41
Idea maybe make a link to the other page and Let some JavaScript fetch this link and or follow this link and let the JavaScript fetch a GUI fragment on this and Bring the GUI fragment in your dome
38:03
Security is one of the most hard and most important parts Because now you have maybe if you have 100 microservices, then you have 100 Contexts with context and all of them has to have a chat
38:21
understanding about security The best idea is to See security and look in look out user user management self administration and things like that see this handle this as own services on microservice columns and
38:41
Then Yeah, bring them together through an identity management thing system or thing like that or protocols like or to for example Which is very good for? Look in distributed environments Yes another slide on this so if you have this there are two two simple possibilities
39:05
The simplest one if they are all the services are available under one domain or the same Top level those second level domain then then it's easy to Let the lock in application create
39:22
one cookie with For example username time stone permissions and things like that crypto school this cookie Sign this cookie and let every service Get this cookie and verify this Ignatius, and then you have a Completely decoupled the different services
39:45
From from calling each other for security and everyone is able to check the the login and signature themselves But of course you have to yeah, I Have to have a commitment between all services to do the look in in this way
40:04
The other variant if maybe you don't have all of these parts in you In your control, and you should for example use or to earn similar protocol Where one makes a redirect to the login service that a reader a dead look in?
40:23
Can be done a redirect to the service again will come and the service can exchange a token so that it Know that he now can trust the user and on Visiting that the user visiting the second service this double redirect can be transparent
40:42
Without that the you without a reader a relook in from the user side, so there's two possibilities to make We have an open-source product we also have the booster have a booster it's called Osean which gives you
41:04
Nice services for exactly it is this look in This case so we have a resource over there within rest interface From skim to standard for accessing the the user data and group data We have an authorization server
41:21
Supporting OAuth 2 for the look in and we have self-administration parts, and I think that that admin UI for the standalone services For the administration and self-administration of the data so communication
41:41
Some I already had said and rest sometimes Rest is of course a favorite of of many people because it's a very simple choice It's very easy to implement. It's implemented between different languages, and so it's the way to do it today, but
42:01
In Microsoft Word you can do communication as you like so you may have different requirements Not to choosing not leading to rest for exam, maybe Principles are that you try to To decouple the
42:23
Services from each other so one service should know as few as possible about the other service but This was something the enterprise service processes promised for a long time don't try to bring any logic or
42:46
Data handling or Maybe not even security in the communication channel, so make it very very thump So only data in data out simple simple things, but of course It may be very good idea to bring something more intelligent in it for example for as in krona scenarios
43:07
or Higher reliability and higher performance or things like that especially in enterprises You would have sometimes have very very
43:20
essential services which Essential to Save them to not get too much load from from rep rep layer So there you need an asynchronous Mode where the the service can fetch everything it wants to do not not getting too much connections for example
43:47
Because you have a distributed system where the action of one may Need action of others you have take Have to be very care careful. What error handling and failure handling is so
44:02
it's very essential that the the the system is able to To redo its job even if failures were there and things like that one word about API versioning I never saw
44:24
successful versioning of remote api's in an internal for internal usage of course if you have external rest services or sub service you have to version them But an internal communication you should don't use this I think so If you have both sides under control
44:42
Then it's a lot easier to to change things together and to to make them upward and backward compatible where possible Testing is a very interesting point on micro services The some You can say that the or some people even say you don't need unit tests
45:05
At all because your servers are getting so small and the thing you would cover by unit tests are so small that it's not worth to test it at all, but Yeah You should not not make a hard rule, but see how to how to cover enough code and
45:25
The integration tests for one service or the component test integration test for one service are getting more and more worth on it and one more worth because the The service itself is the the unit to test most cases
45:41
There's an idea of consumer driven tests, which is hard to to get it working But it's very worthful if you if you get it managed where every consumer in a distributed system defines its own tests and commits its tests in a test pool and the service who wants to release has to pass all the tests of all its consumers because it's
46:07
Yeah, because then you test what the the consumers really want to want to do with your API and not what the service provider thinks he should do Deployment is a big topic where we see all the magic current deployment
46:26
Technology brings us so Of course you have a because of you have more deployments you need 100% automated deployment tools like puppet things like that of everything should be packaged with on a standard Debian or RPM or things like that and
46:45
Robust init scripts and things like that because you have to Have a system, which is very easy handable some hotliners even are thinking currently that you should
47:01
solve the deployment of the application by replacing with the deployment of Complete systems so docker is upcoming since a year now and this is not Yeah, you can It's somewhat something like a change route in usage or like a
47:22
Virtual machine in usage, but it's very lightweight so you can Easily bring docker images up in in in a second for example and ship images to to other locations so Microsoft's hotliners currently are only making the docker image putting the service in it and
47:43
Don't have a packaging or in its scripts or things like that for the service at all And but only ship the image them monitoring of course is a It's a big issue because when you have a lot of services Then you have a distributed monitoring problem, and there are a lot of tools currently supporting this
48:07
There was a good talk on this yesterday So take a look on lockstash graylock cubana and things like that to get multiple services loggable together Also, there's the idea of real-time metrics. There are some Java packages for example on it for it to
48:25
Get the service and rest interface where you can monitor it in real time Where it's where it's up and not only write in lock and yes, this is a result later Okay is my last slide then we have some time for for comments and questions
48:46
For me the the microservice idea is the most essential and biggest idea Currently upcoming so I think it will change on a lot, but of course. It's not not without risks, so
49:02
like every new paradigm You should be very careful should start with simple Small projects and then bigger ones, but in my opinion. This is the this is the only way to Handle the application complexity of big platforms which we have today
49:21
So on a risk side we have the problem that we have to inventory of a lot of services so we have to know where to do which service or where which service running the operation is very challenging so if you have an Standard operations team, then they will get new new things to do and to know
49:43
If not done right you may get Call cascades and a lot of network traffic if you're not doing it right, but I think if you're doing it right then The calls are not that much because if you have to functional splits done Right then you do not should need too much calls to other services
50:07
The Biggest thing maybe it's a it's an Absolutely new way of thinking for for many people and it is not enough to Start the thinking from the developer because if you have a specification
50:20
300-page specification have to build a system, then you already have monolithic specification and To split this up to have functional modules in it. It's not possible at all So you have to start on the application design functional design and start with this maybe have different
50:43
Product managers for different services and things like that and bring your whole whole organization in this mode and the freedom of technology technology selection may also be a big risk because if you don't have a good governance and then It's not only a chance to always stay on your technology, but it's also risk to
51:06
having everyone making What here what he likes to do and you get in cars, of course So that it thank you for listening
51:24
Yes, I think we have to do to use this does it work Okay, this is maybe simpler
52:05
You Have to the standard problem, I think of interdisciplinary. Oh, sorry
52:22
the question was if you have What it becomes and you and you have to you I and you for example want to get a Desktop and mobile application out of it. How would you handle it from a teaming perspective? To serve the mobile UI in every service themselves. So
52:43
For me, it comes back to the problem of interdisciplinary HR teams where you very have it. So it's a It's not easy to get it to get it done, but you should try to put all the experts for every
53:00
for every UI in every team and serve the the mobile interface from every service So every service also should serve its own mobile interface Of course if you can achieve this It's not a problem to bring your one mobile expert and let them implement it for everything
53:25
but then he will identify come parts come code and Will make its own together glued GUI UI for all of this, I think yes, please
53:48
In some point it is more risky if you
54:06
Have your monolith and don't get it really split it into vertical parts then you then you will then we will fail with this because If one car from the end user needs I think say five or ten services
54:23
Then the system will not you will not get the system really robust But if one call only needs one service or two services So one web call then you don't have more risk than with one service even it can be safer because an
54:42
failure or downtime of one service may not Tend that that all the complete application does not run any longer but you have to Invest a lot in automatic deployment and monitoring and things like that it's not so the deployment and monitoring part becomes a lot harder than
55:03
Monolith At the first you should
55:26
Ask you if you need consistency Of course we are from classic from classic Schooling and we add one big thing and we talking about data. We are talking about consistency You should try to to live without consistency if you can handle that
55:44
then it's much more easier and often even if you have one monolithic database system and You think well, I will make it consistent then even in those cases years after Getting life you're mostly get inconsistent
56:01
Inconsistency on some parts and you have to make application logic dealing with inconsistency So this is not not the answer you asked for but this I think it's an important thing To be aware of even make service robust against real consistent data The other thing is um, yeah, you have to to take the right solution for your environment
56:24
So one thing can be if you say, okay, I want this logical approach because I think it's good But I want everything totally consistent. Yes Get a big Oracle stack and make different schemas, but let them work on one monolithic database
56:42
In a bottom and make everything very hard in a database then you only have the logical point of view and the freedom to decide another database store maybe in the future but Have everything together if you decide to Split it 100% then you will lose consistency a lot of
57:04
the noise good database currently are very good and synchronizing data by two different nodes and things like that by by building features And an often done approach is to make something like an atom feed or things like that that every service offers a
57:24
Simple HTTP based feed where other services can pull with change stamps and things like that and replicate the data But on this you have to do a lot of work by hand So this there is no perfect way to do it and you have to Do it on your best opinion
57:43
Behind it I
58:10
Don't think so because My experience, but it's only about meanings My experience is that if you have that and then you have a functional change then you have to
58:22
Go to every layer and change and do the changing on this layers And so you have to your changes function changes are distributed to a lot of different deployment modules So you have another problem? I think if you say I can hand can't handle the mobile client
58:40
Served by every because not so web client maybe by every function unit then the rest representation. I would suggest is simply using the rest API's and Yes using a completely different UI and consume the rest API's it's also oh
59:07
I could talk one hour with you about that and there are some people I know which could then it one more So there it's it's very hard and from performance deployments things and you don't need it in most cases
59:23
So you in most cases, but it's yeah Okay, I got the point that this was the last question if you like to Do discussion I invite you to to come with me and we can talk about it longer. Thank you