Pythonist view on Microservices & Containerization
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 | ||
| Number of Parts | 160 | |
| 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 | 10.5446/33818 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computer architectureService-oriented architectureArchitectureComputer configurationPlastikkarteElasticity (physics)Encapsulation (object-oriented programming)8 (number)Functional (mathematics)Modal logicFile systemService-oriented architectureMereologySingle-precision floating-point formatRevision controlCommunications protocolCycle (graph theory)Software developerStrategy gameCartesian coordinate systemPoint (geometry)Elasticity (physics)Information technology consultingSlide rulePhysical systemView (database)Front and back endsComputing platformCloud computingArchitectureProcess (computing)Suite (music)Self-organizationAreaQuicksortCircleGoodness of fitExpressionMechanism designMiddlewareTerm (mathematics)Different (Kate Ryan album)Dependent and independent variablesCharacteristic polynomialDesign by contractCASE <Informatik>Instance (computer science)Point cloudPattern languageIntegrated development environmentAuthorizationAuthenticationParameter (computer programming)Data storage deviceScaling (geometry)TelecommunicationSoftware engineeringNatural numberServer (computing)BitState of matterConsistencyBuildingVertex (graph theory)Orientation (vector space)Endliche ModelltheorieSystem programmingRule of inferenceExecution unitPlastikkarteLogic gateLevel (video gaming)ImplementationOnline helpWebsitePay televisionWritingObservational studyAutonomic computingTable (information)Mathematical optimizationCellular automatonReading (process)Angular resolutionPower (physics)Intelligent Network
09:01
PlastikkarteElasticity (physics)Encapsulation (object-oriented programming)Service-oriented architectureSingle-precision floating-point formatScalabilityIndependence (probability theory)Maxima and minimaContext awarenessLimit (category theory)Network socketWorld Wide Web ConsortiumRemote procedure callUniform boundedness principleSoftware testingExecution unitCommunications protocolInflection pointVisualization (computer graphics)Virtual realityComputer configurationHypercubeKernel (computing)Computer architectureVideo gameComputer configurationMereologyGoodness of fitQuicksortEncapsulation (object-oriented programming)Point (geometry)Formal languageService-oriented architectureCASE <Informatik>Operator (mathematics)Reflexive spaceMultiplication signSequelDomain nameProcess (computing)ArchitectureDependent and independent variablesConnectivity (graph theory)WeightDatabaseNoise (electronics)ImplementationSoftware developerSlide ruleSingle-precision floating-point formatSoftware maintenanceDifferent (Kate Ryan album)Mathematical analysisCycle (graph theory)Projective planeMetric systemWritingEntire functionLoginUnit testingScripting languageVirtual machineContext awarenessConstraint (mathematics)Social classScalabilityMiddlewareInstallation artTerm (mathematics)INTEGRALStudent's t-testVideo game consoleIntegrated development environmentOptical disc driveDiscrete groupTelecommunicationSoftware testingCommunications protocolWordThermal radiationTemplate (C++)Software frameworkCuboidCombinational logicUniform resource locatorInverse elementFourier seriesIntelligent NetworkTime seriesSocket-SchnittstelleCentralizer and normalizerBuildingImage resolutionCodeSound effectVirtualization2 (number)Wrapper (data mining)Library (computing)Stack (abstract data type)Normal (geometry)Arithmetic meanWeb 2.0Network socketKernel (computing)
18:02
Mobile appInversion (music)Computer-generated imageryRun time (program lifecycle phase)Computer fileInstallation artPoint (geometry)Communications protocolDatabaseSoftware frameworkOverhead (computing)TelecommunicationKolmogorov complexitySystem programmingComputer fileInterface (computing)Medical imagingShift operatorMereologyMobile appData compressionProcess (computing)Characteristic polynomialContinuous integrationDatabaseDatabase transactionImage processingParameter (computer programming)IP addressWebsiteMachine learningString (computer science)RootkitFlow separationVirtual machineOnline helpInstance (computer science)Server (computing)MathematicsSoftware developerCircleAnalytic continuationCASE <Informatik>Software testingRepository (publishing)Slide ruleRevision controlWindows RegistryProjective planePattern languageDataflowService-oriented architectureDirection (geometry)Communications protocolAreaArchitectureOperator (mathematics)Codierung <Programmierung>Complex (psychology)Software frameworkPoint (geometry)Roundness (object)Query languagePhysical systemSystem callSpring (hydrology)Computer architectureFormal languageSystem programmingMetric systemStatisticsConnected spaceQuicksortTelecommunicationOverhead (computing)Different (Kate Ryan album)Product (business)Self-organizationVirtualizationPhase transitionLocal ringSymbol tableDoppler-EffektType theoryLevel (video gaming)Event horizonLogic gateBitCoefficient of determinationSound effectLine (geometry)GezeitenkraftLetterpress printingRight angleGenderArithmetic meanWhiteboardWater vaporGame theory
27:04
System callCASE <Informatik>Point (geometry)Service-oriented architectureDatabaseSlide ruleInstance (computer science)LastteilungBitScalabilityScaling (geometry)CausalityRootkitResultantQuery languageTheory of relativityServer (computing)Perspective (visual)Lecture/Conference
Transcript: English(auto-generated)
00:04
Hello everybody. I'm Abhishek Sharma. I'm a full stack software engineer by heart, who works as a solution consultant at Infochips. I mostly work on providing cloud-based solutions and I've also worked on IoT-based platforms and also the DevOps part of it.
00:28
In my previous organization, I've also built a backend as a service platform, totally in Python, Django, Django REST framework. So, the topic for today is, I'll be presenting my views on microservices and containerization.
00:46
I know there has been a lot of talks on microservices so I have changed my slides a little bit so that we all get to know microservices better. I'll be covering a few areas from the cultural side of how organization adapts microservices and things like that.
01:12
So, let's begin. So, let's define what is microservices. Microservices is an architectural style, I would say.
01:26
To build an application as a suite of small services which communicates with each other with a lightweight protocol. They run on its own process and each service communicates with each other through IPC mechanism.
01:47
You can use any communication protocol like HTTP, RPC or MQP or WebSocket and things like that to communicate between two processes or two services.
02:06
So, when I first read what the microservices is, I was a little bit confused about how it is different from service-oriented architecture and I had the same expression.
02:23
So, differentiating between the two, I realized that microservices architecture is a specialization of service-oriented architecture. So, microservices takes all good parts of service-oriented architecture and is implemented in a different way.
02:47
So, you can see a slight microservices circle coming out slightly. So, there is a sort of difference in approach in implementing microservices. So, as the term micro suggests, it is significantly smaller as compared
03:05
to service-oriented architecture where services are built at a very large scale. So, if you compare two services from SOA and microservices, microservices are significantly smaller.
03:22
They use lightweight protocols to communicate with each other. So, in service-oriented architecture, I think you guys must have seen that there is some kind of middleware we use to communicate between the services. So, if that middleware goes down, your entire application goes down.
03:42
So, that is not the case in the case of microservices. Microservices communicates with each other by defining their own protocols and the contract they agreed upon.
04:01
So, with that definition of microservices, I have listed down the characteristics of what microservices should have. So, if we look at it one by one, it has to be minimal. So, each microservices should adapt a single function responsibility pattern.
04:26
So, let's say if you are writing an e-commerce website and if there is a payment service. So, that service should only be dealing with the payment part. It's okay for other services to not know the underlying implementation, how payment is processed and things like that.
04:44
So, if one service is able to communicate with other services and it is able to get the response, it's okay. The second part is independently deployable. So, as we are talking about distributed systems over here, each individual service has to be independently deployable on our cloud instances.
05:09
So, not only that, even the deployment strategy has to be independent from each other when we talk about service to service.
05:21
So, let's say if you are writing a WebSocket server, then maybe you have to choose the best deployment strategy for that particular service. And maybe a simple authentication or authorization service, then you can maybe go ahead and choose the deployment strategy for that.
05:41
So, deployment strategy can differ from one service to another. The third part is configurable. So, yes, of course, it has to be configured because microservices are autonomous. So, it should be able to self-govern itself and you have to use environment variables, file system mounts or maybe some sort
06:03
of a service discovery or like key-value pair store so that you can read the parameters dynamically and your service acts accordingly. The fourth part is replaceable portions. So, whenever we write a service, we sometimes face problems like this
06:22
service is not acting properly in terms of fulfilling the non-functional requirements. So, we think of writing that service, again, maybe using some different or better architecture. So, your service should be kind of a plug and play nature. So, if at all you are deploying a new version of your service, it should be completely replaceable and your system should work smooth.
06:49
The fifth part is it should be organized around business capabilities. So, I think we have already covered this because each functional areas of your business, your services should focus on implementing those business capabilities.
07:06
The next part is smart endpoints. So, as microservices gives us a lot of flexibility in terms of choosing our own protocols, how one service communicates to another. So, it's good that we choose the best protocol and we define best endpoints so that service can communicate to each other very effectively.
07:29
So, it's not like it should always use HTTP and it should always use TCP or something like that. Choose your protocol wisely so that you get the best performance.
07:44
The next part is elasticity, elasticity in terms of scaling. So, let's say if you are facing a lot of, if you are getting a lot of traffic onto your server. So, your services and your infrastructure should be able to scale up and down based on the necessity.
08:04
The next point is resilience. So, I think microservices needs to be resilient in terms of like if there is a downtime for a particular service, it should not affect the other functionalities of your application.
08:24
The next part is, of course, versioning as we will be developing our services in a very iterative way. So, you should, one should keep their deployment strategies and development cycle according to the versioning.
08:41
So, it should be able to adapt this point. So, infrastructure automation, yes. So, as microservices will be dealing with, as we are dealing with distributed system and it has to be monitored always.
09:00
So, whenever there is a high traffic, so it should be able to scale up and down. So, your infrastructure, you have to decide your infrastructure in such a way that it should allow automatically scaling up and down based on the traffic that you are facing. Centralized logging and monitoring, I have seen people taking this part as an afterthought.
09:24
They generally don't care about this portion, centralized logging and monitoring and they end up facing a lot of issues when they see downtime of a particular service because they will not be able to figure out what's happening wrong.
09:41
So, you should have a centralized dashboard kind of a thing or something where you can look all your logs and monitoring and the monitoring stuffs and things like that. The next part is encapsulation. Your service should cover all the, should have all the components that are required to run that service effectively.
10:04
So, it should not be, it's like if let's say one service requires RDBMS, so it should have all the components near to the service so that they can talk to each other very effectively. And, of course, it has to be stateless.
10:23
So, let's quickly go through what are the advantages of microservices over monolithic architecture. So, the first point is microservices relies on each other public API. So, I've seen a couple of times that in service oriented architecture, most of
10:41
the developers directly communicate with the database of the service and things like that. So, that should not be the case in terms of microservices as we are going to deploy our services independently. So, it has to communicate with the wrapper or the APIs that you built around it.
11:03
The second part is decentralization and no single point of failure. So, we have already discussed that in service oriented architecture there is a concept of middleware which always runs in between so that service can talk to each other effectively. So, if that middleware goes down, so that becomes a single point of failure in terms of service oriented architecture.
11:24
So, in microservices it is not the case. Everything is decentralized and each service talks to each other with the best effective way. The third point is the right tool for the right job. So, with microservices we get a freedom of choosing the technology stack or I would say the best language you can write your services in.
11:52
So, we can write one service in Python or another in Node.js and things like that. So, you get the freedom and you get the flexibility of choosing the right tool for the right job.
12:06
The next thing is polyglot persistence. So, this is kind of like if let's say one microservices requires RDBMS you can go ahead and use any SQL database. And let's say if another service is dealing with let's say for example time series data.
12:24
So, maybe you can then think of choosing the database accordingly and maybe you can go ahead with no SQL database and database of that sort. Single responsibility, as we already discussed, it should be focused more on one aspect of the business requirement.
12:46
I mean one aspect of it. The scalability part, yes, so each service should be developed in a way so that we can scale it up very smoothly. So, even if let's say we are upgrading it so we should be able to upgrade those services smoothly and things like that.
13:08
The next one is decoupled. So, microservices should, I mean the components in the microservices should be loosely coupled and highly cohesive. So, you should develop your microservices in a way so that you can decouple all the components that are there in the services
13:27
and let them talk to each other based on the requirement. The next part is bounded context. It's okay for one services to not know the underlying implementation of the other. So, that is what bounded context means.
13:43
So, the next point is more towards cultural side like end-to-end ownership. So, with the normal software development lifecycle we have seen that projects start from requirement analysis and then it moves toward design and then development. And sooner or later it goes to support and maintenance. So, that is not the case. There is a slight difference here.
14:03
One team owns the entire service development lifecycle over here and they completely own it. And independent governance as well so that they can, because microservices services has to be autonomous. So, it should have all the components that can help us track the monitoring metrics and things like that.
14:28
So, let's move on to how can you write microservices in Python? So, when I heard about it I just googled it out saying like this, what is the best framework to write microservices in Python?
14:42
So, the first thing that I get is about Namako which says that it is a Python framework for building microservices. So, not going to the documentation of it, I have listed down some of the features that it supports. You can install Namako with simple pip install namako.
15:03
The supported protocols through which one service can communicate with each other so it supports these many. You can go ahead and use simple HTTP and get and post. You can do communication over RPC, MQP, you can do pops up, web sockets and it also provides web socket support. So, there are other features as well.
15:23
So, it has a support for unit testing and I guess integration testing as well. So, this is a very feature rich framework as far as microservices is concerned. So, I think this is good but as we all know that microservices, it has to be relatively small.
15:42
We have already seen the minimal point of it. So, it's not a constraint that you have to use, you have to always use this framework. So, if let's say your services only requires HTTP endpoints and things like that, you can go ahead and use Flask. So, that is the kind of freedom that we get when we build microservices.
16:01
So, you can use Flask and let's say if you are dealing with asyncio, you can maybe go ahead and use Django channels or scenic. I guess there was a talk about it in the EuroPython. So, you can choose your frameworks based on your requirement. So, let's see how our services packaged and deployed.
16:21
So, deployment plays a crucial part when we talk about microservices. So, these are the options that I have listed. This first one is traditional like how we used to do in the monolithic. We used to create a script that will SSH to our remote machine and it will check out all our code and then it will try to execute our script.
16:47
But that becomes really difficult when we talk about discrete environment because microservices has to run in discrete environment. So, we are left with the other two options like virtualization and containerization.
17:02
Virtualization, you can go ahead and use virtualization but it becomes quite bulky because it holds the entire OS. So, there will be a guest OS running in your VM boxes so it becomes quite bulky. So, the next thing is containerization which uses Linux kernel capabilities.
17:24
Docker container has this lib container execution environment which directly talks with Linux kernel components. So, you can go ahead and use so that the image size becomes very very small and comparatively it becomes much light weight than hypervisor or VM and things like that.
17:47
So, I'll put this question for you guys like if Docker provides the isolation so do you really need virtual ENV? So, I mean we all know that what virtual ENV is for, it provides good sort of isolation when we talk about Python libraries and things like that.
18:04
But here we are dealing with Docker which provides separate root FS. So, it's okay if you don't use virtual ENV, it's not mandatory but I guess there's no additional text involved as well. So, you can go ahead and use virtual ENV so it's up to you guys whether you want to use it or not.
18:25
Let's move on to how to containerize Python-based services with Docker. So, there are four steps. So, this is a simple Flask app which so on the root it will just return the string Dockerizing Flask app and it will start our server on all the IP addresses on our local instances.
18:44
So, these are the four steps I have listed down all the scripts over here. So, you have to just create your Docker file, you have to say all the commands over there and once that is done you can build your Docker image with Docker build command
19:00
and then you can run the Docker container using Docker run and with the help of Docker ps-a you will be able to see all the Docker container that are running or not running on a particular machine. So, let's talk a little bit about how can we deal
19:20
with continuous integration and continuous deployment approach in microservices and containerization. So, this is with respect to Jenkins but I guess you can also use GitLab CI runners and Circle CI to automate this but this covers the Jenkins part of it. So, let's say when a developer pushes any change to the Git repository with the help of Webhook, Jenkins triggers a build.
19:46
So, Jenkins uses Docker to build an image based on Docker file. So, once your container is up and running you can maybe run all the test cases and if all the test cases are passed then maybe you can push your Docker image to the Docker registry and you can inform all the instances that are running that image to pull the latest version of it.
20:14
So, the next slide is about like when to use microservices. So, I would say don't go with the flow like every big companies are using
20:28
microservices so just don't choose your architecture just by the latest architecture style pattern and technology. So, I would say if decentralization is identified and very inception of your project so maybe you can
20:46
think of writing microservices and maybe if like you are doing a very CPU intensive operation like if you are maybe doing image processing and video encoding or decoding and machine learning and maybe artificial intelligence.
21:03
So, in that case it might be helpful because you might really need to scale those portions, the heavy intensive operation portion in future whenever you face a lot of traffic. So, I think that is the area you can maybe think of when you can choose to go with choosing your architecture as a microservices architecture.
21:34
So, I have talked with most of the developers who are using microservices.
21:42
These are the common mistakes they do when they use microservices. Like in SOA we generally talk with the database directly. So, they use shared database instead of talking through public API they go ahead and directly do the queries to the database.
22:05
So, this is the one mistake that I have seen that people generally do. The second thing is they consider HTTP is the only protocol to communicate between services. Well, that is not the fact. Though writing HTTP services is simpler and it's easy to get
22:24
HTTP services up and running but that doesn't mean that you should only go ahead with HTTP. Maybe a few services are meant to be together so you don't need to do a round trip and do a HTTP call. You can just go ahead and directly communicate with some sort of a TCP connection and things like that.
22:47
The third one is people also end up writing their own service discovery. So, this is in fact I have seen people write microservices for service discovery. So, don't do that. The tools and technologies are very much advanced when we talk about service discovery.
23:08
You can go ahead and use those tools directly. Don't reinvent the wheel. Forcing microservices where it's not required. So, just don't go with the talks that all the big companies are using microservices.
23:23
That's the only reason you have to use microservices. The next point is logging and monitoring as an afterthought. I've already discussed this. People generally take this as an afterthought and they end up facing a lot of troubles when you have to
23:41
identify issues and you have to, let's say, see what are the monitoring statistics and metrics and things like that. One technology and framework everywhere, they end up choosing one language and one particular framework for writing all the services.
24:02
So, don't do that. I think you can choose language that is best suitable for writing your particular microservices. So, I've seen people, especially in Java, use Spring for writing all the HTTP services. So, don't do that. There are microframeworks available even in Java as well.
24:25
We do have a lot in Python. So, especially in the case of Java, I've seen people use a lot of bulky frameworks and they say that it's microservices. So, the next is a tradeoff of using microservices.
24:42
So, these are some of the tradeoffs that I have identified. There are operations and tools cost that is involved. So, you may end up dealing with a lot of tools at the very initial phase of your project. So, there are a lot of cost involved in this.
25:00
The second one is cultural cost. You might be, your team or your organization might not adapt microservices very smoothly. So, you have to maybe convince them. So, there is a lot of cultural cost involved in that because generally what happens in an organization is there is one team for the entire product. But here, we'll be having different teams for different services.
25:25
So, there is a sort of a cultural shift in that part. Distributed system complexity. So, microservices is all about distributed systems. So, it has all the complexity with what we have in distributed systems.
25:42
Interfaces should be well defined. So, documentation is must. So, let's say if I'm working on a, let's say we are working on an e-commerce website and I'm dealing with a payment service. So, I should know, I should tell what parameters am I expecting and things like that very clearly to the other teams.
26:01
So that, you know, they can communicate it accordingly and the transaction becomes much more. The next point is microservices is DevOps first architectural style. So, yes, as it is, as one of the characteristic of microservices is it has to be independently deployable.
26:22
So, I think DevOps thought process is required from the very first day when we start approaching our architecture in microservices way. And the other thing is team communication overhead is there.
26:41
So, you have, you might be communicating a lot across the team about how are you going to communicate and things like that. So, that's why I said the documentation is must so that you can do all your communication effectively and things like that. So, yeah, thank you.
27:05
Thank you, Avichai, for this interesting talk. Are there questions? Thanks for the call. Can you please elaborate a little bit more on the shared database issue?
27:24
Like when is a problem, even if there is replication between database could still be a problem then? Yes. So, what people do is let's say if two services wants to share a particular database. So, what they do is they directly fire a query to the database and get the results.
27:46
So, I think that is not effective when we think about scalability because database might end up becoming the root cause when we think of scalability because we keep on scaling our microservices instances but the database will remain one.
28:02
So, in that perspective, it's good not to make database call directly, use the API so that you are smooth when we talk about scalability and things like that. So, that is what.
28:22
So, in case you say use API, like the API of a microservice connected to the database. Yes, yes, yes, yes. So, it's not more or less the same? So, with API you can have a load balancer in front of it and it can redirect to whatever service instances it can and then you
28:42
can scale the database independently but in case of shared database you might not be able to do that very smoothly. So, that is the point. Okay, thanks. More questions?
29:05
Thank you for the talk. Are your slides available online? There are a few that were quite detailed and I wanted to pick them up later. Sorry, I didn't get. Are your slides available online? So, I'll put it on my GitHub maybe, yeah, so that you can look at it.
29:22
Alright, I see no more questions. So, let's thank Avishak again for his talk.