We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Scaling Microservices with Crossbar.io

00:00

Formal Metadata

Title
Scaling Microservices with Crossbar.io
Title of Series
Part Number
150
Number of Parts
169
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
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 and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Tobias Oberstein - Scaling Microservices with Crossbar.io Microservices offer an efficient way to only scale those parts of your application which are performance bottlenecks. We will demo and explain open source tech which allows the easy scaling out across distributed devices. The audience will be able to donate processor cycles from their devices to our demo application (and win a hardware prize). The demo uses [Crossbar.io], an open souce application router (written in Python), and all demo code is open source. ----- Microservices offer an efficient way to only scale parts of your applications which are hotspots. Instead of running multiple instances of a monolithic application, with all the complexity and operational run-time overhead that entails, you can scale only the functionality which is a bottleneck. Today that increasingly means scaling out, not up. We will go over open source technologies which allow the easy scaling out across distributed devices. A live demo will allow the audience to participate with its devices (including mobile phones) in an application. (There will be prizes for the donors.) The demo uses [Crossbar.io,] an open source router for the open [Web Application Messaging Protocol (WAMP) written in Python. WAMP supports routed Remote Procedure Calls, and Crossbar.io uses these to implement various load-balancing strategies across endpoints which register a particular procedure. WAMP has a first-class library for Python ([Autobahn|Python]), but is cross-language, with support for a total of 11 languages. This allows you to implement polyglot and heterogenos microservices applications, from Python to Node.js to C# right into the browser. Microservices can run anywhere, since the outgoing connections to the router which WAMP uses avoid NAT problems. All software used is open source, and all demo code is provided on GitHub under the MIT license.
11
52
79
Red HatBoom (sailing)Java appletScripting languageErlang distributionSineServer (computing)Open setWorld Wide Web ConsortiumNetwork socketImplementationClient (computing)Firefox <Programm>System callRouter (computing)Service (economics)Link (knot theory)Presentation of a groupMathematical analysisCommunications protocolDifferent (Kate Ryan album)Continuous integrationMathematicsSound effectStatisticsCartesian coordinate systemBasis <Mathematik>ImplementationWeb 2.0Physical systemNetwork socketRemote procedure callUniform resource locatorTwitterFeedbackComputer programmingOpen setDigital electronicsRouter (computing)Web browserServer (computing)Client (computing)1 (number)Formal languageMultiplication signWeb applicationBusiness modelOpen sourceConnected spaceMereologyEmailLibrary (computing)Enterprise architectureWritingLevel (video gaming)SoftwareMultilaterationSoftware frameworkData conversionReal-time operating systemWeb serviceStandard deviationExecution unitDecision theoryDifferential (mechanical device)Closed setRoutingWordRight angleLecture/ConferenceComputer animation
Scaling (geometry)Demo (music)CodeDigital divideMathematical singularityImplementationDependent and independent variablesView (database)Complex (psychology)Travelling salesman problemState of matterCartesian coordinate systemWordIntegrated development environmentRoundness (object)Core dumpLengthRoutingTask (computing)Point (geometry)NumberFlow separationRing (mathematics)Key (cryptography)Service (economics)Connectivity (graph theory)MereologyDifferent (Kate Ryan album)Link (knot theory)Presentation of a groupResultantRootDigitizingCodeDemosceneHeegaard splittingPotenz <Mathematik>NeuroinformatikComplete metric spaceGoodness of fitComputer animation
SimulationBoom (sailing)State of matterParallel portScaling (geometry)Open setSingle-precision floating-point formatTravelling salesman problemCombinatoricsAlgorithmOptimization problemBitState of matterInstance (computer science)NeuroinformatikOrder (biology)Mechanism designSet (mathematics)Virtual machineMultiplication signRule of inferenceSpacetimePoint (geometry)Insertion lossOpen sourceFood energyClosed setConnectivity (graph theory)Scaling (geometry)Cartesian coordinate systemVideo gameMaxima and minimaMereologySurfaceEnergy levelSingle-precision floating-point formatCore dumpGradient descentServer (computing)PhysicalismCost curveSimulated annealingEndliche ModelltheorieRootHeuristicInfinityHeat transferLimit (category theory)Loop (music)RoutingComputer animationLecture/Conference
Parameter (computer programming)Core dumpSystem callInformationDistributive propertyWorld Wide Web ConsortiumRouter (computing)Social classInternetworkingCurve fittingNeuroinformatikMereologyTravelling salesman problemMobile appoutputPattern languageEvent horizonCommunications protocolPerturbation theoryNumberAbstractionTrailService (economics)NamespaceCategory of beingInstance (computer science)ComputerInformationServer (computing)Remote procedure callComputer architectureHeegaard splittingConnectivity (graph theory)Inheritance (object-oriented programming)MathematicsUser interfaceBefehlsprozessorRootRule of inferenceVarianceStructural loadGroup actionProcess (computing)1 (number)Boilerplate (text)WebsiteRoutingParametrische ErregungMikrocomputerConnected spaceSpacetimeLinear subspaceSoftwareFirewall (computing)ResultantDistribution (mathematics)Virtual machineMultiplication signCartesian coordinate systemFunction (mathematics)Endliche ModelltheorieMathematical optimizationSet (mathematics)CommutatorWeb applicationPoint (geometry)Game controllerWeb 2.0WeightNetwork socketObject (grammar)Router (computing)Uniform resource locator2 (number)Peer-to-peerRaw image formatMultiplicationDifferent (Kate Ryan album)AngleParameter (computer programming)Core dumpLecture/ConferenceComputer animation
Maxima and minimaSystem callEvent horizonGroup actionSystem callMereologyPresentation of a groupDifferent (Kate Ryan album)CodeProcedural programmingBitRemote procedure callFunctional (mathematics)Pay televisionFinite-state machineAuthorizationProcess (computing)Mechanism designNamespaceConnectivity (graph theory)SoftwareWeightResultantCartesian coordinate systemNumberLevel (video gaming)Fiber bundleRight angleConvolutionBasis <Mathematik>Lecture/ConferenceProgram flowchart
System callEvent horizonImage registrationPerturbation theorySingle-precision floating-point formatControl flowMaxima and minimaLimit (category theory)ComputerWeb browserAsynchronous Transfer ModeDifferent (Kate Ryan album)Connectivity (graph theory)MultiplicationScaling (geometry)Concurrency (computer science)Event horizonProcedural programmingPerturbation theorySystem callInstance (computer science)Maxima and minimaCuboidVirtual machinePhysicalismThread (computing)Image registrationComputer architectureGroup actionInteractive televisionContext awarenessComputer configurationRandomizationService (economics)Error messageFormal languageComputerSingle-precision floating-point formatUsabilityScalar fieldInsertion lossUniform resource locatorRoundness (object)Mathematical analysisEndliche ModelltheorieStandard deviationGraph coloringProcess (computing)CASE <Informatik>Moment (mathematics)Observational studyComputer animation
Router (computing)Archaeological field surveyMaxima and minimaEmailBitDemo (music)CodeLink (knot theory)Archaeological field surveyCartesian coordinate systemDifferent (Kate Ryan album)Pattern languageSet (mathematics)MereologyInteractive televisionInternet der Dinge1 (number)Process (computing)Right anglePower (physics)Connected spaceMetropolitan area networkOrder (biology)Software development kitPerturbation theoryRouter (computing)Scaling (geometry)Remote procedure callLink (knot theory)EmailProcedural programmingLecture/ConferenceComputer animation
Boom (sailing)Client (computing)Scaling (geometry)AuthorizationGame controllerEvent horizonToken ringMathematicsBlack boxWebsiteExecution unitSound effectCuboidPhysical systemProduct (business)MereologyHigh availabilitySystem callProcedural programmingMechanism designDirection (geometry)Goodness of fitVideo gameExtension (kinesiology)Instance (computer science)Process (computing)DatabaseConnectivity (graph theory)EncryptionInformation securityPrice indexQuicksortCore dumpLevel (video gaming)Point (geometry)1 (number)Data storage deviceSynchronizationRight angleOpen sourceCartesian coordinate systemAuthenticationSubsetLibrary (computing)Design by contractHookingService (economics)Device driverThread (computing)SoftwareParallel computingScalabilityPhase transitionBootingPoint cloudInteractive televisionLecture/Conference
Boom (sailing)WebsiteLink (knot theory)Projective planePoint (geometry)Integrated development environmentView (database)WaveUser interfaceData centerInternet der DingeOpen setWeb 2.0LastteilungWeb serviceLevel (video gaming)WritingConnected spaceMobile appLine (geometry)Different (Kate Ryan album)Boilerplate (text)Uniform resource locatorStructural loadVirtual machineCategory of beingData managementNetwork socketFocus (optics)SurfaceConnectivity (graph theory)Axiom of choiceInformation securityService (economics)SoftwareFeedbackReal-time operating systemShooting methodCartesian coordinate systemWeightFluid staticsCache (computing)Server (computing)Chaos (cosmogony)Core dumpCode2 (number)Dependent and independent variablesFacebookCASE <Informatik>PlastikkarteNatural languageProduct (business)Event horizonForm (programming)Observational studyWordFood energyMereologySet (mathematics)Reverse engineeringMobile WebProxy serverDigital electronicsChemical equationEndliche ModelltheorieSoftware developerQuicksortSubgraphScaling (geometry)PlotterInstance (computer science)Phase transitionDistribution (mathematics)Lecture/Conference
Red HatComputer animation
Transcript: English(auto-generated)
Oberstein, who's going to be speaking about scaling microservices with Crossbar. I owe. So hello. Yeah, my name is Tobias I'm giving a talk about scaling micro services or micro service in generally with cross bio, but specifically Scaling micro services the talk is online or the presentation is online
So there will be a lot of links inside, but you don't have to write them down. So just Just open that URL Well, my name is Tobias you can find me on Twitter and various social
channels under that Nick and that's my email if you want to give me a Feedback or have further questions. Don't hesitate. Just contact me via email or Twitter Yeah, my background is in math and statistics I've been programming since I was 12 which is quite a long ago
I've been doing programming in different languages a lot of them I regularly use nowadays CC plus plus SQL JavaScript the other ones less and of course my preferred language is Python these days. So
There's one language. I still want to learn that's rest That's missing in my my repertoire still because it's an interesting language Other than that, I'm spending most of the time in part so Apart from program, I'm founder of Tevendo and cross bio a startup and we do messaging servers
so We also with it open source and community supporter we so we started a lot of open source libraries and cross bio itself is also open source Regarding the startup we have a commercial open source business model
So that usual thing the software everything is open source But if you want to have commercial support for cross by all you can get that from us So that's pretty much standard in yeah, well enterprise software, you know that business model
Well, I mentioned that we started a lot of initiatives open source libraries One of them is Audubon you've probably heard of it was the first web socket implementation in Python You can use it to write web socket clients as well as servers so you can use it at the pure web socket level
And it also implements the web application messaging protocol, which we will be using for Micro services, so we'll talk about that later Audubon supports to Asynchronous networking frameworks under the hood. So that's twisted in a single and runs on Python 2 and 3 and
So you can use it like if you're a twisted guy then you can use it in a twisted application But you can also use it in an async I or application Audubon is used More and more. It's a biggest user probably from deployment side is
Firefox they use it for active push So that's a browser feature in your browser feature and they have like serving like 80 million connections currently using Audubon and Want to ramp up that to the whole user base? That was quite a thrill
Having conversation design because it's a difference if you have like to 1000 web socket connections versus 80 million their new effects new new challenges like like keeping them alive and stuff like this and It's also will be Basis for build.9. That's a continuous integration system also written in Python
Then it's used in jungle channels. So jungle it's it's a Have some more real-time features, so that's that's also user
Then web application messaging protocol that's also started by us, but it's an open ecosystem. So it's an open open protocol We just want implementers nowadays So there are third-party implementations of the protocol and the story is like a web circuit It's it runs natively over over web socket, which is real-time bi-directional and stuff like this
But it's quite low-level so we figured we needed some some more abstract for for writing application want something more Abstracted so what the one protocol implements? remote procedure calls and publish subscribe We'll get back to that later
Well, yes cross by all it's about router so web application messaging protocol is a rooted protocol So you need a router? There are different routers cross by OS our warm prouter, but they're different warm prouter So you're not locked into our stuff. That was because I was mentioning one business open ecosystem
So we from the beginning we said no, we don't want to look into lock Users into our stuff so you can have different implementations or it can use different implementations as well And Well, there are a lot of links the presentation then we have a mini demo code
Which is kind of stripped down that's the second one and then we have a bigger application That's not quite we've tried to finish it until today, but it's not totally finished But a lot of code is already working. You can have a look there. It's all in github. So just give it a try
Okay, just very briefly what's what's microservices what's the story about that I won't go much into detail, but just to do a quick intro So this is something you don't want to have
What you usually have if you have a monolith application you end up with a big pile of spaghetti Sooner or later, so it usually starts small and everything is great and works But in the end after a couple of months or years it piles up and in the end it looks like this
So what's the deal the deal is about taming complexity? So that's the overarching story Why do you want to have microservices? It's because you want to tame the complexity to not get sunk in in some spaghetti hell So that would break down into D wide and conqueror. So you want to have smaller parts which are more manageable
One thing should have only one responsibility. So not not Shuffling everything into one one piece and one piece does everything so you want to have separation of concerns And then we want to have decoupling. So that's that's a pretty important point. You have want to have your your parts
Contained and then basically Minimize the coupling between the components. So that's the approach to tame complexity and Well, that's of course a longer Has a history. It's not not new that that theme of taming complexity and
splitting down stuff is pretty old and there were different approaches of different technologies trying to do that carver decom and Soap is probably the worst of all Well, I've done for example C++ with Carver which is not nice you have to be a massive hiss
To stand that basically or to to survive that and in the end it's it's just doesn't work or it's it's too complex So and we also see why rest and HTTP isn't really an answer or not at least a complete answer For micro services. So if you think Microsoft is most people are not saying say, okay
Let's use HTTP rest. That's that's works. That's good enough, but we'll see why that isn't enough So we will you look at the micro service how you approach micro services in an application
based on an example and The example is a traveling salesman problem So we will look at the traveling salesman problem and the application and how to break that down into micro services And how what are the challenges and how you would do that? So just very quickly the traveling salesman problem, what's what's that?
So imagine a salesman that has to visit a couple of cities so the big the fat ring, that's the start point and The the task for the salesman is to visit all the cities exactly one or each city exactly once and then come back
to the starting point So in the and the the task is find the route which is shortest so salesman wants to travel fast wants to Wants to Minimize the lengths of the round trip around the cities so
This will be one solution But not the shortest path So with that few cities it's it's obvious what would be the shortest path probably this one and Now the problem is how do you find that a solution
Computationally and how do you find it if the number of cities is growing because the problem is that's It grows the number of possible routes grows pretty fast. It's Exponentially it grows exponentially so Always sunny cities is already a huge number. I can't even read how many digits a lot of digits so
Exhaustively Looking at each possible route isn't practically possible. So we need something better
Yeah Well, that's just just a wrap-up. So the traveling salesman problem is a combinatorial optimization problem and the search space looking for a solution that's exponentially large and There isn't a deterministic or a closed solution to that problem
So the problem is a closed solution, but traveling salesman is not one of them So we'll look at one way to solve that just very briefly that simulated annealing So if you have a search space now in one dimension, that's the x-axis and you have a cost function
that that gives the cost depending on the Particular solution in the search space you're looking basically looking at an energy surface or cost surface and The problem is that you don't want to get stuck in if you if you now try for example gradient descent
You pretty much get stuck in a local minimum and simulated annealing tries to avoid that by by clever clever Heuristic to to look inside the search space and search for the best solution. So it isn't isn't
Let's try to avoid that getting stuck in a local minimum and How do you do that? So we don't need to understand the details of the algorithm but there is an important point where there is a repeat n times loop and That's the important point because we use that to to scale out the microservice. So we will have a
compute microservice component and And we want to scale that out and to be able to do that we need to have in the algorithm a place where we can split up the problem into sub problems and then Distribute to each instance of the compute compute microservice part of the the problem
so if you're interested it works like you start with the initial temperature and In healing that's the ideas like if you if you have a melted melted material and cool it down it will If you if you cool it down slowly, it will get into the minimum energy state
so that's just transfer of that idea into an algorithm And so you should start with initial temperature and the initial state which can be any other just a random route and Then you repeat that until you you've reached a lower end temperature and
Then you you just have starting from your current solution You perturbate that solution a little bit just like swap two cities The the order in which they visited swap those and then have a look again at the modified route is the energy is the coast lower if it's lower than you take the new route and
If it's higher you nevertheless take the new route even if the coast is higher With a certain probability that depends on the temperature and that's the trick because that avoids to get stuck into a local minimum early early in While while running so there's there's always a little bit
Unless the temperature is zero. There's always a non zero probability of taking a Worse route so that gets you out of the local minimum But that's not it it's just an example the important point is that we have a repeat n times part in the algorithm
Which we can use to to distribute to our multiple instances of the compute servers Well, that's why don't we run it on one core just and that's enough because The answer is simple because there are no
There's a limit based in or rooted in physics you we don't just don't have like like Infinite fast single core machines, so we have to use multiple cores How would we use multiple cores for that problem in an application solving trailing salesman
We could use some I talk mechanisms This is not what we're talking or what I will be talking about because that's a talk mechanisms just for the compute problem Are we talking about just using microservices also for the compute part also for scaling the compute part?
and Well now TSP app how does does it look we have a vacation that the input is the problem? Our compute time budget, and we just want to have the as an output the best route found in that
compute time budget So the app has to do Made basically three things so it needs to control the overall search the orchestration of the search It has to have a user interface We want to be able to look at the route or control the parameters and it needs the compute core
multi instances of the compute core so Splitting up that into a microservice Application would probably look like this so we have now split up the monolith the big monolith in different in different parts and
The different parts we have the user interface Microservice parts we have compute parts, and we have the orchestrator so This is the TSP app from a microservice angle or in the microservice split down Architecture now the thing is these components need to talk to each other
So for example the orchestrator that controls the overall optimization needs to Needs to call into the compute instance instances of the my compute microservice for sub parts of the search space compute me your best route within your subspace of search and
Then it wants to get back the result best route for that sub problem on subspace of the search space So it need we need something to call into the confirm the orchestrator Microservice to call into the compute servers and get back a result, so that's pretty straightforward
But we also want to have something like events Like the compute servers. What's my current load on the on the machine running that instance of the compute microservice It probably needs one thing we want to see what's the CPU load currently how many roots per second are? Processed by that particular instance of the compute microservice
So we need something something different, which is event we want to distribute information to the other part so the orchestrator wants probably to track all the CPU loads of the instances of the micro compute microservice, and we want to show that in the in the user interface as well
So we need two patterns Remote procedure call and publish subscribe Idly in one protocol in one technology that makes it easier and that's That's one way is using the web application Messaging protocol because we figured initially that we we want to have something at more abstracts and peer than raw web socket
And we need those two messaging patterns in one protocol So how does it work We have app components components of microservice I will use it synonymously
and those are Initially connecting to crossbar crossbar is a router one prutter. So code wise that looks like this This is the twisted variant How do you establish sessions from the components from the microservices to crossbar? I won't go much into detail
but in the end you get a session object which itself and then you can have those actions for the two messaging patterns for remote procedure calls and for Publish subscribe for publishing and and receiving events so that's just kind of boilerplate which you need to establish a session and then
To actually run a session you have this boilerplate I will not go into details, but you can see there's a ws in the application run at that URL That means it runs over web socket okay, so
Pattern number one publish subscribe ideas. You have an abstract namespace your your eyes which was names where the names are topics, so the Decoupling between the publisher and the subscriber side is via that namespace via that your eyes
The publisher publishes to the abstract topic cross bar knows or the one cruder knows who is subscribed on that topic and can distribute the B events again So to app components could subscribe like the UI I subscribe to see on CPU load change
All the back and the orchestrator on CPU load change and then The compute component can publish when the CPU load changes or each second for example periodically publish my CPU load and the subscribers would then receive the CPU load and
The point is both don't need to know about each other. So we have that decoupling So the publisher side doesn't need to know where who subscribe where are my subscribers where are they currently residing They could be behind network be behind netted networks and behind the firewalls and so on
So we have that decoupling for that pattern. Oh Okay, miss that. That's the distribution of the event then to the actual subscribers So cold wise it looks like this pretty easy you have a call event handler on hello That should be fired when you receive an event on your subscription and to subscribe you just say session subscribe
you say what's my event handler and your URI so that's pretty straightforward a Subscription can fail basically only for for one reason. That's you're not allowed to subscribe So they are their authorization mechanisms in crossbar where you can finally control who is allowed which role is allowed to
subscribe who is allowed to publish or not and Yeah, well publish looks like this so you have Basically also on the session of that session publish so you can publish your data
So how do Remote procedure called look look This is also again decoupled with a namespace your eyes are decoupling the caller and callee side so a callee says I provided for a procedure and This is callable under this URI and then the caller can call the procedure under the URI
But both don't need to know where physically the other one resides. So we again have a decoupling So this looks again like this you were a component registers When then as a call incoming cross by knows who has registered the the procedure and can forward the call to the callee
The callee produces a result and the result is then shuffled back to the original caller So again, we have a decoupling between caller and callee Which is pretty much a different to rest HTTP because with rest HTTP the caller needs to know
Where's the host name and the port number which I'm trying to call? So there you have a coupling to your deployment infrastructure and you have a coupling in from your application code to your deployment Infrastructure and you don't want to have that So we transferred that pattern from publish subscribe the decoupling to the part to the remote procedure call
Well register looks like this need to fasten up a little bit I think Just code wise you can have a look on the presentations online Call can be done like this
So it's pretty pretty straightforward session call and you have the only difference basically to a direct function called the yield there Which which you should recognize that's asynchronous code. So it's not a synchronous in process call, but it's out of process It does network stuff, but it's asynchronous. Therefore the yield you can't have in newer in Python 3.5
You could have a weight basically So that's just that's Python 2 compatible code, but in Python 3.5, there would be a weight at that place And you can of course combine those actions So you can call the procedure in an event handler and then publish events from a register procedure if it's called and stuff like this
So it's all pretty much you can combine that to create more complex interactions Then shared registration that's the feature which we will be using for scanning out market services if we have to normally one Procedure can only be registered once the second one gets an error already registered
But in crossbow, we have a feature called shared registration Which allows the same procedure to be registered by multiple instances of a service or instance of a component and How does it work then if there's or how is it usable?
It's usable because crossbow then can for example implement hot standby for you So you can have all the calls routed to the main primary component until That component fails and then all further calls are Transparently routed to the hot standby component and the caller doesn't need it doesn't
Isn't aware of that so it's totally transparent so you have hot failover for micro services like that's one use and the other one for for the problem here is this Scalar so you can have calls routed to different components or multiple instances of the component in a round-robin fashion
so that allows you to to scale because you can run those instances on different machines and It's again transparent completely transparent for the caller side The caller side doesn't need isn't even isn't even aware of the fact that there are multiple instances on the quality side
It's just transparent So Shared registrations that isn't it's not context at all It's just a single option that you have to to give on the register was it when you're registering the the procedure It's invoke round-robin. So we have different invocation policies round-robin is one
Random like single first last or different invocation policies will be using round-robin. It's simple straightforward to understand So then there's another feature because if you if you then say okay, that's enough Normally a component can take in
Arbitrary amount of calls like if you have a Python component, that's it's a single thread It doesn't make sense to send it like 100 calls if it's only single threaded if you if you make it multi-threaded or if you have a component with its multi-threaded then you can't probably take in many calls in parallel, but that's
You should be able to control that concurrency. Otherwise your component just gets overwhelmed by incoming calls or invocations So that's another feature which is pretty much necessary for for practical use It's max concurrency You can register a call you can register and give max concurrency say I'm able to do that many
concurrent calls to process that many concurrent calls So Again, that's pretty easy. It's another option during the register You just give the concurrency you're able to serve and crossbow will note that and then it will not ever
Send more than that many calls concurrently to your component So that way you can prohibit Okay I'm too slow. Sorry Okay PSP app, so this is the architecture looks like then
So we all connect the crossbar Of course, you can have those components written in different languages so we support more than 12 languages and Then you can combine those components or place the components on different boxes machines physical machines
So you can have the orchestrate the computer machine one two different compute instances of the neck and next machine and so on Summary yes microservices new new answer old problem We've seen that Carver and everything else But we think that's that's a new new answer to the old problem a better answer than before
we have seen those two connection patterns or Interaction patterns remote procedure called publish subscribe which we think are pretty much always Necessary or most often necessary in practical applications
And then we've seen how that is made easy by cross by an order ban Scaling and hot standby are offered by the router in particular cross by Oh, there isn't currently the one fruit is different by feature sets cross by is the most advanced one So not every one brutal or currently it's the only one that supports that
Yeah, we also have price draw with two Iot starter kits we are pretty much into the Internet of Things We've got two of these you can win these
If you take the survey, you don't have to provide your email. We don't want to have your personal data just feedback so Please visit these links take take part in the survey and you can win two of these
Okay, that's that's my talk So any questions? Yeah Yes, so crossbar. I know it's like a black box that handles everything or do you deploy it yourself and
if you deployed Yourself no, but does it have like a few notes does it know do high availability if one note fails? And you you can you can deploy it on your own premises. So it's open source You can it's open source. You can just download it deployed in your bare metal on your in your cloud and
AWS we also have docker Support so you can just talk run crossbar basically and you're you're up and running but it's right It's a black box as is it should be looked at as a black box. You can also install it like pip install crossbar But you should look at it like like Apache or nginx like a black box system. So
We we're still working on that on the on the scale out part of cross of the routing core itself So that that is in the work on and we're working with that. That's probably I can't tell after that more Okay, so thank you for your talk hope that we managed to use
Database with crossbar. I mean we have to We need database interaction. So does it have to be asynchronous to Well, you can have the database interaction in from your components So you can have a component which is just using SQL alchemy to talk to your database or whatever
We will also have this upcoming thing which is a post process Connector which will allow you to directly use one right into the database. So you can for example call a Postgres SQL stored procedure like any other warm start was a warm procedure
So you can call from JavaScript directly into a stored procedure in Postgres I swear you can publish events warm events from a trigger in Postgres SQL Okay, so it doesn't have to be asynchronous on your in your component You can be some you could you could create a component and let it be synchronous, right?
If you if you mentioning like like database libraries are usually synchronous There there are ways to to work around that So postgres SQL for example has also asynchronous really asynchronous database drivers others Like if you have Oracle CX Oracle, it is synchronous, but you can run it You have to run it then on the background thread
So otherwise it blocks your primary thread which is doing the asynchronous program networking So but there's there are ways to to handle that Thank you for a talk and for talk and my question is
Your scenario is real nice because it's very easy just talking between micro services But I'm afraid to use these products because when I need to make authorization let's say My clients need to get some of the data
it's it's scary because how do I pass my tokens from the user to the To the let's say autobahn or crossbar or when I pass them Let's say my authorization change and these problems Well, well, they're probably different aspects we have authentication mechanisms built into crossbar
We also have extensions for extension points in crossbar. We can hook into the authentication phase Pretty much by just implementing a WAMP component again, which is then called curing the authentication they can plug into
Proprietary authentication System and then we have role-based authorization which means you can finally control which who is allowed Who is allowed to subscribe who is allowed to publish for example? The one the sensor in an IT application could be allowed to publish but not to subscribe even to its own topic
So you can have finally controlled Well authorization of those actions But that there are many aspects like you're mentioning like Encryption or security or in what direction is you? Nice example is a
user can see different Instances there is instances. So one user can see only two instances and I have a topic named instances in the crossbar. Let's say so How do I send a user only is instances Yeah, you can you can either have the the role-based
Authorization mechanism where the specific user is authenticated under a specific role and only under that role He is able to receive his own events or the events He should be able to receive and you also can have that's called exclude and eligible You can have but that's an advanced feature now probably we'll talk after that
You can control even for the individual publication down to the session level who is Who should receive that event? So not all the subscribers which are basically authorized and subscribe but even a subset
You can you can have exclude and eligible, but let's let's talk. It's probably true To show that code, but you can pretty much finally control who is allowed to do what and who is and we should get what event or Whatever so that there's a lot of stuff inside. So we're pretty much paranoid on the security side. So that's
Maybe also an answer Hey, thanks for your talk One question you mentioned like the routing you do the main feature is the decoupling I See that but it also seems to me now that you introduced a very tight coupling to crossbar to like a third component and
Solving that in the like HTTP case would involve something like you can use a load balancer or something like smart stack So like how would you respond to that? Do you think it's this is more of a?
Convenience that it's easier to set up and get everything running or do you have a different point of view? I have a different point of view because at the application level Crossbar is invisible From your code. It's it's it's only visible in the initial connection establishment But but that's a couple of lines of boilerplate somewhere in your application
The rest or in your microservice the rest of your microservice code is totally unaware of the fact that there's a intermediary so and Regarding your point with the HTTP rest doing load balancing then you're pretty much reinventing what we did because then the the load balancer needs to know who where are my rest and points and
When they change when the one machine goes down it needs to be updated the load balancer Needs to be so there's a whole category of startups a the API management for microservices for rest based Microservices, so that's a whole category which from our point of view is is doing it the wrong way
But of course, that's that's all of you But I think you're starting down the road reinventing the stuff We do that that that decoupling will be based on your load balancer on your nginx or whatever But when you have to to manage that that needs to know where are my rest and points and and the other problem is
We've not talked about that but it's all open ports all your microservices are basically web service with open ports So you have a pretty much big attack surface With crossbar you only have outgoing connections from the components from the microservice. There are no listening ports
So for example, that's not only a problem on the security side It's only also a problem on the networking side if your microservices behind a net it's not reachable from outside So rest doesn't work so you can shoot shoot shoot open ports
UPnP or whatever, but that's security hell and So but with crossbar you can have your app component your microservice sitting behind the net doesn't matter because it's only one outgoing connection So there's advantage and security on network side. Yeah Just would you normally deploy it behind nginx or is it the first thing you'd hit crossbar?
Please I didn't would you normally deploy deploy crossbar behind nginx. You can of course many people do that Deploy that behind nginx for basically serving static web assets from nginx from the caching and then just Reverse proxying the web socket connections to crossbar
But I would say we personally we ourselves we just run plain crossbar So there's a web server built in we've done benchmarking like it It's chaos on 40 cores to 600,000 web requests per second can shuffle more than 10 gig per second HTTP response traffic so we don't have a need for nginx if you like Facebook then probably yes
And you need nginx, but so nginx will be faster on the pure Serving static web assets, but for our use cases you don't need it pretty much What's that?
I'm sorry. Thank you I saw on your website. I mean So on your website an IOT link which is seems not to work now
but you have a lot of projects with Crossbar in an embedded environment or something like this I Well the the Internet of Things Industry 4.0. It's the most important user base or users for us because it's a big wave coming and
There you have inherently distributed applications if you're writing like like a holiday planner you can still Decide if it's a monolith or it's if it's a microservice app because in the end it will run in the data center Only there, but if you have an Internet of Things application with different locations moving vehicles
Data center back ends mobile devices and whatever then that's inherently already distributed so there isn't the choice between monolith and micro services or because it's inherently turned distributed already
and While we have a lot of feedback or uptake in in the Internet of Things So we users of crossbar are either Doing it for like I want to make my web user interface real-time. That's one user the other one says okay, I have I run a Bitcoin exchange want to have some real-time stuff, but the
Biggest or most interest from our point of view is Internet of Things. So that's that's pretty much a focus for us Yeah Okay, I see there's still people with questions left I would invite you to go afterwards during lunch or right now or whenever go grab this guy and ask your questions
And we're gonna get to the next speaker. Thank you Tobias