kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fix video overlay bug and other CSS issues with case studies (#8954) 

* fix css for ny times case study

* fix for bla bla car
pull/8814/merge
Zach Arnold 2018-06-06 14:11:24 -07:00 committed by k8s-ci-robot
parent e690ca416e
commit f0179aeb0d
4 changed files with 233 additions and 233 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
content/en/case-studies/blablacar.html
View File

@ -7,7 +7,7 @@ css: /css/style_blablacar.css
---
<div class="banner1">
<h1> CASE STUDY:<img src="/images/blablacar_logo.png" class="header_logo"><br> <div class="subhead">Turning to Containerization to Support Millions of Rideshares</div></h1>
<h1> CASE STUDY:<img src="/images/blablacar_logo.png" class="header_logo"><br /> <div class="subhead">Turning to Containerization to Support Millions of Rideshares</div></h1>
</div>
@ -15,15 +15,14 @@ css: /css/style_blablacar.css
Company &nbsp;<b>BlaBlaCar</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Paris, France</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Ridesharing Company</b>
</div>
<hr>
<hr />
<section class="section1">
<div class="cols">
<div class="col1">
<h2>Challenge</h2>
The world’s largest long-distance carpooling community, <a href="https://www.blablacar.com/">BlaBlaCar</a>, connects 40 million members across 22 countries. The company has been experiencing exponential growth since 2012 and needed its infrastructure to keep up. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Simon Lallemand, Infrastructure Engineer at BlaBlaCar. "The answer is not to hire more and more people just to deal with the servers and installation." The team knew they had to scale the platform, but wanted to stay on their own bare metal servers.
<br>
<br>
<br />
<br />
<h2>Solution</h2>
Opting not to shift to cloud virtualization or use a private cloud on their own servers, the BlaBlaCar team became early adopters of containerization, using the CoreOs runtime <a href="https://coreos.com/rkt">rkt</a>, initially deployed using <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> cluster manager. Last year, the company switched to <a href="http://kubernetes.io/">Kubernetes</a> orchestration, and now also uses <a href="https://prometheus.io/">Prometheus</a> for monitoring.
</div>
@ -34,19 +33,18 @@ css: /css/style_blablacar.css
</div>
</div>
</section>
<div class="banner2">
<div class="banner2text">
"When you’re switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br>- Simon Lallemand, Infrastructure Engineer at BlaBlaCar</span>
"When you’re switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before."<br style="height:25px"><span style="font-size:14px;letter-spacing:2px;text-transform:uppercase;margin-top:5% !important;"><br />- Simon Lallemand, Infrastructure Engineer at BlaBlaCar</span>
</div>
</div>
<section class="section2">
<div class="fullcol">
<h2>For the 40 million users of <a href="https://www.blablacar.com/">BlaBlaCar</a>, it’s easy to find strangers headed in the same direction to share rides and costs. You can even choose how much "bla bla" chatter you want from a long-distance ride mate.</h2>
Behind the scenes, though, the infrastructure was falling woefully behind the rider community’s exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."<br><br>
By 2015, the company had about 50 bare metal servers. The team was using a <a href="https://www.mysql.com/">MySQL</a> database and <a href="http://php.net/">PHP</a>, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, <a href="https://www.chef.io/chef/">Chef</a>, but had little automation in its process. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."<br><br>
Instead, BlaBlaCar began its cloud-native journey but wasn’t sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn’t want to go to virtualization on premise.<br><br>
Behind the scenes, though, the infrastructure was falling woefully behind the rider community’s exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."<br /><br />
By 2015, the company had about 50 bare metal servers. The team was using a <a href="https://www.mysql.com/">MySQL</a> database and <a href="http://php.net/">PHP</a>, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, <a href="https://www.chef.io/chef/">Chef</a>, but had little automation in its process. "When you’re thinking about doubling the number of servers, you start thinking, ‘What should I do to be more efficient?’" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."<br /><br />
Instead, BlaBlaCar began its cloud-native journey but wasn’t sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn’t want to go to virtualization on premise.<br /><br />
The solution: containerization. This was early 2015 and containers were still relatively new. "It was a bold move at the time," says Lallemand. "We decided that the next servers that we would buy in the new data center would all be the same model, so we could outsource the maintenance of the servers. And we decided to go with containers and with <a href="https://coreos.com/">CoreOS</a> Container Linux as an abstraction for this hardware. It seemed future-proof to go with containers because we could see what companies were already doing with containers."
</div>
</section>
@ -59,10 +57,10 @@ css: /css/style_blablacar.css
<section class="section3">
<div class="fullcol">
Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with <a href="https://www.docker.com/">Docker</a> but decided to go with <a href="https://coreos.com/rkt">rkt</a>. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time, the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.<br><br>
Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand’s team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you’re focused on your product sometimes you forget if it’s really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."<br><br>
After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as <a href="https://github.com/blablacar/dgr">dgr</a>, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools <a href="https://github.com/airbnb/nerve">Nerve</a> and <a href="http://airbnb.io/projects/synapse/">Synapse</a>; their versions, <a href="https://github.com/blablacar/go-nerve">Go-Nerve</a> and <a href="https://github.com/blablacar/go-synapse">Go-Synapse</a>, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.<br><br>
At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It’s now at 100 percent.) "It’s a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."<br><br>
Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with <a href="https://www.docker.com/">Docker</a> but decided to go with <a href="https://coreos.com/rkt">rkt</a>. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time, the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.<br /><br />
Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand’s team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you’re focused on your product sometimes you forget if it’s really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."<br /><br />
After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as <a href="https://github.com/blablacar/dgr">dgr</a>, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools <a href="https://github.com/airbnb/nerve">Nerve</a> and <a href="http://airbnb.io/projects/synapse/">Synapse</a>; their versions, <a href="https://github.com/blablacar/go-nerve">Go-Nerve</a> and <a href="https://github.com/blablacar/go-synapse">Go-Synapse</a>, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.<br /><br />
At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It’s now at 100 percent.) "It’s a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."<br /><br />
In the middle of that peak season for carpooling, everything worked well. "The biggest impact that we had was for the deployment of new services," says Lallemand. "Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it’s really a huge gain. For the developers, it means they can focus only on the features that they’re developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."
</div>
</section>
@ -75,10 +73,10 @@ css: /css/style_blablacar.css
<section class="section4">
<div class="fullcol">
In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> tool from CoreOS to deploy their containers. (They did build a tool called <a href="https://github.com/blablacar/ggn">GGN</a>, which they’ve open-sourced, to make it more manageable for their system engineers to use.)<br><br>
Still, the team knew that they’d want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don’t want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in <a href="http://kubernetes.io/">Kubernetes</a>, which had just begun supporting rkt implementation.<br><br>
After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using <a href="https://prometheus.io/">Prometheus</a>, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.<br><br>
BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It’s really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."<br><br>
In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic <a href="https://coreos.com/fleet/docs/latest/launching-containers-fleet.html">fleet</a> tool from CoreOS to deploy their containers. (They did build a tool called <a href="https://github.com/blablacar/ggn">GGN</a>, which they’ve open-sourced, to make it more manageable for their system engineers to use.)<br /><br />
Still, the team knew that they’d want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don’t want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in <a href="http://kubernetes.io/">Kubernetes</a>, which had just begun supporting rkt implementation.<br /><br />
After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using <a href="https://prometheus.io/">Prometheus</a>, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.<br /><br />
BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It’s really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."<br /><br />
The team is particularly happy that they’re now able to plan capacity better in the company’s data center. "We have fewer constraints since we have this abstraction between the services and the hardware we run on," says Lallemand. "If we lose a server because there’s a hardware problem on it, we just move the containers onto another server. It’s much more efficient. We do that by just changing a line in the configuration file. And with Kubernetes, it should be automatic, so we would have nothing to do."
</div>
</section>
@ -91,10 +89,10 @@ css: /css/style_blablacar.css
<section class="section5">
<div class="fullcol">
And these advances ultimately trickle down to BlaBlaCar’s users. "We have improved availability overall on our website," says Lallemand. "When you’re switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."<br><br>
Within BlaBlaCar’s technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different ‘tribes’—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster." <br><br>
This DevOps transformation turned out to be a positive one for the company’s staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants." <br><br>
With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don’t say microservices because they’re not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have." <br><br>
And these advances ultimately trickle down to BlaBlaCar’s users. "We have improved availability overall on our website," says Lallemand. "When you’re switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."<br /><br />
Within BlaBlaCar’s technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different ‘tribes’—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster." <br /><br />
This DevOps transformation turned out to be a positive one for the company’s staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants." <br /><br />
With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don’t say microservices because they’re not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have." <br /><br />
When Lallemand speaks to other European companies curious about what BlaBlaCar has done with its infrastructure, he tells them to come along for the ride. "I tell them that it’s such a pleasure to deal with the infrastructure that we have today compared to what we had before," he says. "They just need to keep in mind their real motive, whether it’s flexibility in development or reliability or so on, and then go step by step towards reaching those objectives. That’s what we’ve done. It’s important not to do technology for the sake of technology. Do it for a purpose. Our focus was on helping the developers."
</div>
</section>

45
content/en/case-studies/newyorktimes.html
View File

@ -6,7 +6,7 @@ css: /css/style_case_studies.css
---
<div class="banner1" style="background-image: url('/images/CaseStudy_newyorktimes_banner1.jpg')">
<h1> CASE STUDY:<img src="/images/newyorktimes_logo.png" class="header_logo"><br> <div class="subhead">The New York Times: From Print to the Web to Cloud Native
<h1> CASE STUDY:<img src="/images/newyorktimes_logo.png" class="header_logo"><br /> <div class="subhead">The New York Times: From Print to the Web to Cloud Native
</div></h1>
@ -18,48 +18,43 @@ css: /css/style_case_studies.css
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>News Media</b>
</div>
<hr>
<hr />
<section class="section1">
<div class="cols">
<div class="col1">
<h2>Challenge</h2>
When the company decided a few years ago to move out of its data centers, its first deployments on the public cloud were smaller, less critical applications managed on virtual machines. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center," says Deep Kapadia, Executive Director, Engineering at The New York Times. Kapadia was tapped to lead a Delivery Engineering Team that would "design for the abstractions that cloud providers offer us."
<br>
<br />
<h2>Solution</h2>
The team decided to use <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.
<br>
<br />
</div>
<div class="col2">
<h2>Impact</h2>
Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.
<br>
<br />
</div>
</div>
</section>
<div class="banner2" style="padding-bottom:0% !important">
<div class="banner2text" style="width:100% !important;padding-left:5% !important;padding-right:5% !important">
<div class="video" style="float:left;width:90%;">
<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<div class="banner2">
<div class="video">
<iframe width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<iframe width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
</div>
</div>
</div>
<div class="banner2" style="padding-top:5% !important">
<div class="banner2text" style="padding-top:3% !important">
<div class="banner2text" style="padding-top: 1em;">
"I think once you get over the initial hump, things get a lot easier and actually a lot faster." — Deep Kapadia, Executive Director, Engineering at The&nbsp;New&nbsp;York&nbsp;Times</div>
</div>
</div>
<section class="section2">
<div class="fullcol">
Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.<br><br>
At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on <a href="https://aws.amazon.com/">AWS</a> as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."<br><br>
To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.<br><br>
At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"<br><br>
Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.<br /><br />
At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on <a href="https://aws.amazon.com/">AWS</a> as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."<br /><br />
To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the <a href="https://cloud.google.com/">Google Cloud Platform</a> and its Kubernetes-as-a-service offering, <a href="https://cloud.google.com/kubernetes-engine/">GKE</a>.<br /><br />
At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"<br /><br />
In early 2017, the first production application—the nytimes.com mobile homepage—began running on Kubernetes, serving just 1% of the traffic. Today, almost 100% of the nytimes.com site’s end-user facing applications run on GCP, with the majority on Kubernetes.
</div>
@ -72,9 +67,9 @@ css: /css/style_case_studies.css
<section class="section3">
<div class="fullcol">
The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."<br><br>
The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, which has been the main platform for the company’s experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I’m really excited about experimenting with deploying those on App Engine Flex and <a href="https://aws.amazon.com/fargate/">AWS Fargate</a> and seeing how that feels, because that’s a great migration path."<br><br>
There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they’re using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."<br><br>
The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."<br /><br />
The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on <a href="https://cloud.google.com/appengine/">Google App Engine</a>, which has been the main platform for the company’s experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I’m really excited about experimenting with deploying those on App Engine Flex and <a href="https://aws.amazon.com/fargate/">AWS Fargate</a> and seeing how that feels, because that’s a great migration path."<br /><br />
There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they’re using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."<br /><br />
Kapadia acknowledges that there was a steep learning curve for some engineers, but "I think once you get over the initial hump, things get a lot easier and actually a lot faster."
</div>
@ -87,8 +82,8 @@ css: /css/style_case_studies.css
</div>
<section class="section5" style="padding:0px !important">
<div class="fullcol">
At The New York Times, they did. As teams started sharing their own best practices with each other, "We’re no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We’ve sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, ‘If this works for you as is, great! If not, come talk to us and we’ll figure out how to make it work for you.’"<br><br>
As a result, "It’s really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."<br><br>
At The New York Times, they did. As teams started sharing their own best practices with each other, "We’re no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We’ve sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, ‘If this works for you as is, great! If not, come talk to us and we’ll figure out how to make it work for you.’"<br /><br />
As a result, "It’s really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."<br /><br />
Another benefit to adopting Kubernetes: allowing for a more unified approach to deployment across the engineering staff. "Before, many teams were building their own tools for deployment," says Balser. With Kubernetes—as well as the other CNCF projects The New York Times uses, including Fluentd to collect logs for all of its AWS servers, gRPC for its <a href="https://open.nytimes.com/publishing-with-apache-kafka-at-the-new-york-times-7f0e3b7d2077">Publishing Pipeline</a>, Prometheus, and Envoy—"we can benefit from the advances that each of these technologies make, instead of trying to catch up."
</div>
@ -101,7 +96,7 @@ Li calls the Cloud Native Computing Foundation’s projects "a northern star tha
</div>
<div class="fullcol">
These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We’re running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."<br><br>
These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We’re running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."<br /><br />
Li calls the Cloud Native Computing Foundation’s projects "a northern star that we can all look at and follow." Led by that star, the team is looking ahead to a year of onboarding the remaining half of the 40 or so product engineering teams to extract even more value out of the technology. "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."
</div>

9
static/css/style_blablacar.css
View File

@ -59,17 +59,16 @@ h1 {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
padding-top:4%;
padding-bottom:4%;
padding: 1%;
width:100%;
font-size:24px;
letter-spacing:0.03em;
line-height:34px;
float:left;
background-size:100% auto;
background-color:#666666;
background-repeat:repeat;
position: relative;
display: inline-block;
}
.banner3 {
@ -125,6 +124,8 @@ h1 {
padding-left:18%;
float:left;
text-align:center;
z-index: 1;
padding-top: 2%;
}
.banner3text {

360
static/css/style_case_studies.css
View File

@ -249,202 +249,208 @@ h4 {
padding-bottom:0px;
}
@media screen and (max-width: 910px){
h1 {
font-family:"Roboto", sans-serif;
font-weight:bold;
line-height:36px;
letter-spacing:0.03em;
font-size:30px !important;
padding-bottom:0px;
width:80%;
.video {
text-align: center;
height: auto;
}
.header_logo {
width:35%;
margin-bottom:-.5%;
magin-left:10px;
}
.subhead {
font-size:18px;
font-weight:100;
line-height:27px;
}
@media screen and (max-width: 910px) {
.details {
font-family:"Roboto", sans-serif;
font-weight:300;
font-size:16px;
color:#3366ff;
letter-spacing:0.03em;
padding-bottom:2%;
line-height:28px;
padding-top:4%;
padding-left:10%;
}
h1 {
font-family: "Roboto", sans-serif;
font-weight: bold;
line-height: 36px;
letter-spacing: 0.03em;
font-size: 30px !important;
padding-bottom: 0px;
width: 80%;
}
.logo {
width:8%;
}
.header_logo {
width: 35%;
margin-bottom: -.5%;
magin-left: 10px;
}
.col1 {
.subhead {
font-size: 18px;
font-weight: 100;
line-height: 27px;
}
.details {
font-family: "Roboto", sans-serif;
font-weight: 300;
font-size: 16px;
color: #3366ff;
letter-spacing: 0.03em;
padding-bottom: 2%;
line-height: 28px;
padding-top: 4%;
padding-left: 10%;
}
.logo {
width: 8%;
}
.col1 {
width: 95%;
padding-right:8%;
float:left;
font-family:"Roboto", sans-serif;
font-weight:300;
color:#606060;
line-height:20px;
letter-spacing:0.03em;
font-size:14px;
}
padding-right: 8%;
float: left;
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #606060;
line-height: 20px;
letter-spacing: 0.03em;
font-size: 14px;
}
.col2 {
.col2 {
width: 95%;
padding-top:2%;
padding-bottom:5%;
font-family:"Roboto", sans-serif;
font-weight:300;
float:left;
line-height:20px;
color:#606060;
letter-spacing:0.03em;
font-size:14px;
}
padding-top: 2%;
padding-bottom: 5%;
font-family: "Roboto", sans-serif;
font-weight: 300;
float: left;
line-height: 20px;
color: #606060;
letter-spacing: 0.03em;
font-size: 14px;
}
.banner1 {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
padding-top:15%;
padding-bottom:2%;
padding-left:10%;
font-size:18px;
background-size:100% auto;
}
.banner1 {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
padding-top: 15%;
padding-bottom: 2%;
padding-left: 10%;
font-size: 18px;
background-size: 100% auto;
}
.banner2 {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
padding-top:4%;
padding-bottom:4%;
font-size:18px;
letter-spacing:0.03em;
line-height:24px;
width:100%;
float:left;
background:none;
background-color:#666666;
}
.banner2 {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
padding-top: 4%;
padding-bottom: 4%;
font-size: 18px;
letter-spacing: 0.03em;
line-height: 24px;
width: 100%;
float: left;
background: none;
background-color: #666666;
}
.banner3 {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
padding-top:5%;
padding-bottom:5%;
font-size:16px;
letter-spacing:0.03em;
line-height:23px;
width:90%;
float:left;
}
.banner3 {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
padding-top: 5%;
padding-bottom: 5%;
font-size: 16px;
letter-spacing: 0.03em;
line-height: 23px;
width: 90%;
float: left;
}
.banner4 {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
padding-top:4%;
padding-bottom:4%;
font-size:18px;
letter-spacing:0.03em;
line-height:24px;
width:100%;
float:left;
}
.banner4 {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
padding-top: 4%;
padding-bottom: 4%;
font-size: 18px;
letter-spacing: 0.03em;
line-height: 24px;
width: 100%;
float: left;
}
.banner5 {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
padding-top:4%;
padding-bottom:4%;
font-size:16px;
letter-spacing:0.03em;
line-height:23px;
width:100%;
float:left;
background:none;
background-color:#666666;
}
.banner5 {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
padding-top: 4%;
padding-bottom: 4%;
font-size: 16px;
letter-spacing: 0.03em;
line-height: 23px;
width: 100%;
float: left;
background: none;
background-color: #666666;
}
.banner2text {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
width:90%;
padding-left:5%;
padding-bottom:1%;
padding-top:1%;
float:left;
text-align:center;
color:#ffffff;
}
.banner2text {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
width: 90%;
padding-left: 5%;
padding-bottom: 1%;
padding-top: 1%;
float: left;
text-align: center;
color: #ffffff;
}
.banner3text {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
width:90%;
padding-left:5%;
padding-top:5%;
padding-bottom:5%;
text-align:center;
}
.banner3text {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
width: 90%;
padding-left: 5%;
padding-top: 5%;
padding-bottom: 5%;
text-align: center;
}
.banner4text {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
width:90%;
padding-left:5%;
padding-top:3%;
padding-bottom:3%;
text-align:center;
}
.banner4text {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
width: 90%;
padding-left: 5%;
padding-top: 3%;
padding-bottom: 3%;
text-align: center;
}
.banner5text {
font-family:"Roboto", sans-serif;
font-weight:300;
color:#ffffff;
width:90%;
padding-left:5%;
padding-top:3%;
padding-bottom:3%;
text-align:center;
}
.banner5text {
font-family: "Roboto", sans-serif;
font-weight: 300;
color: #ffffff;
width: 90%;
padding-left: 5%;
padding-top: 3%;
padding-bottom: 3%;
text-align: center;
}
.fullcol {
margin-top:6%;
margin-bottom:8%;
}
.fullcol {
margin-top: 6%;
margin-bottom: 8%;
}
h2 {
line-height:26px;
font-size:18px;
}
h2 {
line-height: 26px;
font-size: 18px;
}
.quote {
font-size:18px;
line-height:24px;
}
.quote {
font-size: 18px;
line-height: 24px;
}
.logo {
width:35%;
.logo {
width: 35%;
}
}
@media screen and (max-width: 580px){
@ -456,7 +462,7 @@ h2 {
margin-top:2%;
}
.banner2text {
padding-top: 2% !important;
}
}