This is the future
Good day.
I bring to your attention a translation of a humorous post devoted to cloud technologies: It's The Future . All sorts of amendments and tips are welcomed.
')
Hey! Hello! My boss said to talk to you. Said you know a lot about web applications.
- Yes, right now, I’m more involved in distributed systems. I just came back from ContainerCamp and GlueCon, and I'm also going to DockerCon next week. Really impressed with how a business moves - everything becomes much easier and more accessible! This is the future!
Great ... You see, I am currently developing a simple web application - the usual CRUD on Rails, I am going to deploy to Heroku. Tell me, is Heroku still relevant?
- You what! Not. This is already an old school. Heroku is a corpse. Nobody uses this anymore. Now you need to know Docker. This is the future!
Oh, here's how. Well, OK. What is it?
- Docker - a new way of containerization. It's like LXC, it just includes the format of packing containers, and it’s also a distribution platform and a number of utilities to make building a distributed system really easy.
Canning? .. - What for? And what about LXE?
- LXC. It's like chroot on steroids.
What is cher-oot?
- I see ... Look ... Docker ... Containerization ... This is the future ... It's like virtualization, only faster and cheaper.
Okay, like Vagrant.
- No, Vagrant is a corpse. Now everything is being prepared for use inside containers. This is the Future!
Ok, so now I don’t need to know anything about virtualization?
- Well ... No, you need to understand virtualization, because containers do not provide full protection for application data, for now. So, if you want to run everything in a multi-tenant environment, then you will need to make sure that users do not get out of the sandbox.
So, something I lost. Let's rewind a little back. So, there is virtualization called containers. Can I use it on Heroku?
- Well, Heroku supports Docker, but remember what I told you. Heroku is a corpse. You need to run containers on CoreOS.
What is it?
- This is the coolest host OS you can use with Docker. Damn, you don’t even need a Docker! You can just use rkt!
Rocket?
- Not, rkt.
Right, Rocket.
- No, now it is called rkt. Completely different stuff. This is an alternative containerization format that is provided as a Docker competitor.
Duck is this cool?
- Of course, cool. Composability is the future!
Do you use this rkt at all?
- I dont know. I don't think anyone is using it.
Ehhh ... So you said something about CoreOS?
- Yes ... well, this is the host that you use with Docker.
What is a host?
- CoreOS is designed to work optimally with containers. It is configured to work with containers.
Work with containers ...?
- Yes, you have something there in your containers. So, you type an instance like Amazon EC2, raise a CoreOS host there, then you launch the Docker service, and then you can deploy Docker images there.
What part of all this is a container?
- All of this. Look, you take your application, write a Dockerfile, make a local image, then push to any Docker-host.
Aah, like Heroku?
- No ... not Heroku. I told you that Heroku is a corpse. You run your own cloud using Docker.
O_o?
- Yes, it is really easy. Read about #gifee.
Gify?
- GIFEE is Google Infrastructure For Everyone Else. You take all of these utilities and technology-based stacks of containers, and you have all that infrastructure, just like Google.
Why not just use Google services?
- And if in half a year everything is completely changed there?
Well, isn’t someone else doing it all? I really do not want to host this one myself.
- Well, AmazonECS, but you have to write some kind of XML her.
What do you say about OpenStack?
- Ugh ...
Listen, I do not want to host and service anything myself.
- No, it's real simple. You simply configure Kubernetes cluster.
So I need a cluster?
- Kubernetes cluster. It manages the deployments of all your services.
I have only one service.
- What are you talking about? Look, you have the same web application, right? So you should have 8-12 services.
What? Not! I have one application. Service, service - do not care! Just one freaking app!
- No, look towards microservices. This is the future. This is how we all work around now. You take your superfood app and divide it into 12 services. One for each task.
Well, this is too much ...
- This is the only way to make sure the configuration is reliable. So if your authentication service crashes ...
Authentication service? Yes e-May, I was just going to use the same plugin that I used many times before!
- Great. Use it. Put it in a separate project. Throw over RestAPI. Then your other services will use this API and will super gracefully handle failures. Put it in a container and make a CI / CD!
As you wish. Now I have dozens of unmanaged services in my hands, and then what?
- Yes, and so, I also spoke about Kubernetes. It allows you to conveniently orchestrate all of your services.
Orchestrate?
- Yes! Here, you have these services of yours, and they must be fault-tolerant, so you need to run several copies for each of your services at once! And Kubernetes guarantees to you that you have enough of these copies and they are distributed between the hosts in your fleet and are always available.
That is, I need fleet?
- Yes, for fault tolerance. But Kubernetes will do everything for you. In addition, you are sure that Kubernetes will work as it should, because it was made by Google, and also because it works on the basis of etcd.
What is etcd?
- This thing is made on the basis of RAFT.
OK, what is RAFT?
- It's like paxos.
Lord, how deep is this shitty rabbit hole, where are we going now? I just want to launch one crazy web application !!! Your mother !!! Okay, deep breath, exhale ... Ok, what is Paxos?
“Paxos is an old family of distributed protocols from the 70s that no one understands or uses.
Fine! I'm so glad you told me about it! So what is Raft?
“Since no one understands Paxos ... uh ... except Diego ...”
ABOUT! So you know him?
- No, of course, it works in CoreOS. Anyway, Diego came up with Raft for his Ph.D. thesis, because Paxos was too complicated. Damn smart people. And then he wrote etcd as an implementation, and then Aphyr said that this is really not shit, but cool !!!
Who is Aphyr?
- Aphyr - well, this is the person who wrote "Call Me Maybe", well ... you know him? "The distributed systems and BDSM guy"?
Did you just say bdsm?
- Yes, BDSM. This is San Francisco. Here everyone is passionate about distributed systems and BDSM.
And he wrote that Katy Perry song?
- No, he wrote a series of articles about how each database floods CAP.
What is CAP?
- Teroema about CAP (also known as the Brewer theorem). She says that you can only have 2 points out of three: Consistency, Accessibility and Resistance to Splitting.
And all databases flood this CAP? What the fuck is all about?
“That means all this sucks.” Like MongoDB.
I thought MongoDB is horizontally expandable .
- No one but you.
Okay. So what's up with etcd?
- Yes, and so, etcd is a distributed storage of values.
Just like Redis.
- No, not at all like Redis. etcd is a distributed system. Redis loses some information if the network temporarily fails.
Well, this is a distributed repository of values. Why is this thing so useful?
- Kubernetes configures a standard cluster of five nodes using etcd as a messaging bus. It combines with a pair of its own services to provide a very stable orchestral system.
5 knots? I have one application. How many cars do I need to pick up for this?
- Well, you are going to raise 12 services, and of course you need a couple of extra copies for each, a pair of balancers, etcd, your database and Kubernetes cluster. So, it can be about 50 containers at the same time.
Chzh
- Yes, finally can not question! The containers are really efficient, so it’s easy for you to distribute the whole thing between 8 machines! Isn't that awesome?
And yet, this is just your impression. And taking this all, can I just deploy my application?
- Well, of course! True, data storage volumes are still an open question in the case of Docker and Kubernetes, and the network load is increased, but these issues will be solved very soon!
Hmm, I see. Well, it seems I now understand everything.
- Great!
Thanks for the detailed story.
- Yes, no problem.
Let me just summarize everything we talked about to make sure that we understand each other.
- Of course!
So, I simply need to divide my simple CRUD application into 12 microservices, each of which should be wrapped in its own API, which should call each other using these APIs, but at the same time handle the errors of each of them, put all this into containers Docker, run fleet of 8 machines that are CoreOS-based Docker-hosts, “orchestrate them” using a small Kubernetes cluster based on etcd, solve “a couple of open questions” about network load and information storage, set up multiple copies CI / CD each microservice with balancer vschikami in fleet. It's like that?
- Yes! Isn't that awesome?
... I'll go to Heroku.
I bring to your attention a translation of a humorous post devoted to cloud technologies: It's The Future . All sorts of amendments and tips are welcomed.
')
Hey! Hello! My boss said to talk to you. Said you know a lot about web applications.
- Yes, right now, I’m more involved in distributed systems. I just came back from ContainerCamp and GlueCon, and I'm also going to DockerCon next week. Really impressed with how a business moves - everything becomes much easier and more accessible! This is the future!
Great ... You see, I am currently developing a simple web application - the usual CRUD on Rails, I am going to deploy to Heroku. Tell me, is Heroku still relevant?
- You what! Not. This is already an old school. Heroku is a corpse. Nobody uses this anymore. Now you need to know Docker. This is the future!
Oh, here's how. Well, OK. What is it?
- Docker - a new way of containerization. It's like LXC, it just includes the format of packing containers, and it’s also a distribution platform and a number of utilities to make building a distributed system really easy.
Canning? .. - What for? And what about LXE?
- LXC. It's like chroot on steroids.
What is cher-oot?
- I see ... Look ... Docker ... Containerization ... This is the future ... It's like virtualization, only faster and cheaper.
Okay, like Vagrant.
- No, Vagrant is a corpse. Now everything is being prepared for use inside containers. This is the Future!
Ok, so now I don’t need to know anything about virtualization?
- Well ... No, you need to understand virtualization, because containers do not provide full protection for application data, for now. So, if you want to run everything in a multi-tenant environment, then you will need to make sure that users do not get out of the sandbox.
So, something I lost. Let's rewind a little back. So, there is virtualization called containers. Can I use it on Heroku?
- Well, Heroku supports Docker, but remember what I told you. Heroku is a corpse. You need to run containers on CoreOS.
What is it?
- This is the coolest host OS you can use with Docker. Damn, you don’t even need a Docker! You can just use rkt!
Rocket?
- Not, rkt.
Right, Rocket.
- No, now it is called rkt. Completely different stuff. This is an alternative containerization format that is provided as a Docker competitor.
Duck is this cool?
- Of course, cool. Composability is the future!
Do you use this rkt at all?
- I dont know. I don't think anyone is using it.
Ehhh ... So you said something about CoreOS?
- Yes ... well, this is the host that you use with Docker.
What is a host?
- CoreOS is designed to work optimally with containers. It is configured to work with containers.
Work with containers ...?
- Yes, you have something there in your containers. So, you type an instance like Amazon EC2, raise a CoreOS host there, then you launch the Docker service, and then you can deploy Docker images there.
What part of all this is a container?
- All of this. Look, you take your application, write a Dockerfile, make a local image, then push to any Docker-host.
Aah, like Heroku?
- No ... not Heroku. I told you that Heroku is a corpse. You run your own cloud using Docker.
O_o?
- Yes, it is really easy. Read about #gifee.
Gify?
- GIFEE is Google Infrastructure For Everyone Else. You take all of these utilities and technology-based stacks of containers, and you have all that infrastructure, just like Google.
Why not just use Google services?
- And if in half a year everything is completely changed there?
Well, isn’t someone else doing it all? I really do not want to host this one myself.
- Well, AmazonECS, but you have to write some kind of XML her.
What do you say about OpenStack?
- Ugh ...
Listen, I do not want to host and service anything myself.
- No, it's real simple. You simply configure Kubernetes cluster.
So I need a cluster?
- Kubernetes cluster. It manages the deployments of all your services.
I have only one service.
- What are you talking about? Look, you have the same web application, right? So you should have 8-12 services.
What? Not! I have one application. Service, service - do not care! Just one freaking app!
- No, look towards microservices. This is the future. This is how we all work around now. You take your superfood app and divide it into 12 services. One for each task.
Well, this is too much ...
- This is the only way to make sure the configuration is reliable. So if your authentication service crashes ...
Authentication service? Yes e-May, I was just going to use the same plugin that I used many times before!
- Great. Use it. Put it in a separate project. Throw over RestAPI. Then your other services will use this API and will super gracefully handle failures. Put it in a container and make a CI / CD!
As you wish. Now I have dozens of unmanaged services in my hands, and then what?
- Yes, and so, I also spoke about Kubernetes. It allows you to conveniently orchestrate all of your services.
Orchestrate?
- Yes! Here, you have these services of yours, and they must be fault-tolerant, so you need to run several copies for each of your services at once! And Kubernetes guarantees to you that you have enough of these copies and they are distributed between the hosts in your fleet and are always available.
That is, I need fleet?
- Yes, for fault tolerance. But Kubernetes will do everything for you. In addition, you are sure that Kubernetes will work as it should, because it was made by Google, and also because it works on the basis of etcd.
What is etcd?
- This thing is made on the basis of RAFT.
OK, what is RAFT?
- It's like paxos.
Lord, how deep is this shitty rabbit hole, where are we going now? I just want to launch one crazy web application !!! Your mother !!! Okay, deep breath, exhale ... Ok, what is Paxos?
“Paxos is an old family of distributed protocols from the 70s that no one understands or uses.
Fine! I'm so glad you told me about it! So what is Raft?
“Since no one understands Paxos ... uh ... except Diego ...”
ABOUT! So you know him?
- No, of course, it works in CoreOS. Anyway, Diego came up with Raft for his Ph.D. thesis, because Paxos was too complicated. Damn smart people. And then he wrote etcd as an implementation, and then Aphyr said that this is really not shit, but cool !!!
Who is Aphyr?
- Aphyr - well, this is the person who wrote "Call Me Maybe", well ... you know him? "The distributed systems and BDSM guy"?
Did you just say bdsm?
- Yes, BDSM. This is San Francisco. Here everyone is passionate about distributed systems and BDSM.
And he wrote that Katy Perry song?
- No, he wrote a series of articles about how each database floods CAP.
What is CAP?
- Teroema about CAP (also known as the Brewer theorem). She says that you can only have 2 points out of three: Consistency, Accessibility and Resistance to Splitting.
And all databases flood this CAP? What the fuck is all about?
“That means all this sucks.” Like MongoDB.
I thought MongoDB is horizontally expandable .
- No one but you.
Okay. So what's up with etcd?
- Yes, and so, etcd is a distributed storage of values.
Just like Redis.
- No, not at all like Redis. etcd is a distributed system. Redis loses some information if the network temporarily fails.
Well, this is a distributed repository of values. Why is this thing so useful?
- Kubernetes configures a standard cluster of five nodes using etcd as a messaging bus. It combines with a pair of its own services to provide a very stable orchestral system.
5 knots? I have one application. How many cars do I need to pick up for this?
- Well, you are going to raise 12 services, and of course you need a couple of extra copies for each, a pair of balancers, etcd, your database and Kubernetes cluster. So, it can be about 50 containers at the same time.
Chzh
- Yes, finally can not question! The containers are really efficient, so it’s easy for you to distribute the whole thing between 8 machines! Isn't that awesome?
And yet, this is just your impression. And taking this all, can I just deploy my application?
- Well, of course! True, data storage volumes are still an open question in the case of Docker and Kubernetes, and the network load is increased, but these issues will be solved very soon!
Hmm, I see. Well, it seems I now understand everything.
- Great!
Thanks for the detailed story.
- Yes, no problem.
Let me just summarize everything we talked about to make sure that we understand each other.
- Of course!
So, I simply need to divide my simple CRUD application into 12 microservices, each of which should be wrapped in its own API, which should call each other using these APIs, but at the same time handle the errors of each of them, put all this into containers Docker, run fleet of 8 machines that are CoreOS-based Docker-hosts, “orchestrate them” using a small Kubernetes cluster based on etcd, solve “a couple of open questions” about network load and information storage, set up multiple copies CI / CD each microservice with balancer vschikami in fleet. It's like that?
- Yes! Isn't that awesome?
... I'll go to Heroku.
Source: https://habr.com/ru/post/276539/
All Articles