A variety of conversation topics and a whole lotta short stacks were served to the huge crowd who turned out for The New Stack’s pancake breakfast at the SpringOne 2GX conference in Washington, D.C.
For this edition of The New Stack Analysts podcast, recorded live at the event, Alex Williams spoke with Jon Schneider and Taylor Wicksell, senior software engineers at Netflix; Groovy programming language project lead Guillaume LaForge, and Graeme Rocher, Grails project lead at OCI; and James Watters, VP of Cloud Platform Group at Pivotal.
For more episodes, check out the podcast section of The New Stack.
This podcast is also available on YouTube.
Setting the table for the discussion, Jon and Taylor discuss the genesis of Netflix’s open source software, and the fruits of Netflix’s collaboration with Pivotal.
“NetflixOSS components were built initially for a data center; about 2010, Netflix started migrating entirely to the cloud,” says Taylor. “At this point, for the most part, Netflix is operating entirely in AWS. That’s a really similar story for a lot of businesses who are currently managing their own data centers, and are looking to first become cloud-ready, and finally become cloud native.”
Taylor says that every NetflixOSS component can be run on a laptop or in a data center. “Once you’ve baked that infrastructure into your code base, you’re ready to make that jump to the cloud.”
“Spring Cloud Netflix, in terms of ease-of-startup and documentation, is far above what we had done internally,” says Jon. “That’s something we were really excited to see: an external entity taking ownership of some of these libraries and making them easy to use.”
That excitement has inspired Netflix to make Eureka 2.0, Ribbon 2.0, and other patterns within Spring Cloud Netflix a lot easier for people to consume. “We’re actually using Boot internally as a way of doing that,” Jon adds, describing many of their 2.0 efforts coming out this year as “clean-up.”
“Our platform was not dependency injection-driven initially,” Jon explains, “so we’ve re-worked a lot of that on the back of Juice, and we’re making bindings for Juice and Spring for each of our core libraries. You’ll see a lot of clean up, a lot of performance enhancements, a lot of extra documentation where that was lacking, because that’s some consistent feedback we’ve gotten from the community.”
Taylor is also excited to announce the imminent open sourcing of Spinnaker, “a complete re-write” of the Asgard UI for application deployment and management in the Amazon cloud.
One way in which Spinnaker is an improvement over Asgard is the addition of pipelines that enable adding stages, in order to take code from a .deb package to scaling it up, according to Taylor. “It’s less tied to particular elements in the AWS console, and more focused on defining an application and the pipeline that it takes to get it to production,” he says.
Next up, Guillaume discusses the Groovy project, which joined the Apache Incubator in March. “We really wanted to send an important message to the community that the project was there for the long run,” he says of Groovy joining Apache, “and also to gather new contributors, and have a more widespread usage of Groovy in other Apache projects as well.” Consequently, the numbers of downloads has doubled compared to last year.
In light of the numerous open source software foundations from which to choose, Guillaume explains the considerations which led them to committing to Apache — one consideration being that they were already compatible, since Groovy has used the Apache license for a long time.
Secondly, had they chosen to join the Eclipse Foundation, they would have had to erase Groovy’s entire GitHub history in order to accomodate a clean import of the code base. “We didn’t want to tell past contributors, ‘All your commits are gone now.’ We wanted to say, ‘This stub was made by this person, this other stub by someone else.’ We didn’t want to erase all that stuff,” says Guillaume.
“Apache is also quite visible as well,” he continues. “When companies have to choose a language, or a tool, or a library, or anything — seeing that it’s coming from Apache, there’s an implicit trust already put into that kind of project hosted there.”
“I think Netflix is probably the largest web-scale deployment of Groovy,” says Guillaume, adding that PayPal’s API orchestration layer is also built using Groovy.
Groovy is fixing bugs and improving stability as they settle in with the Apache Foundation, with a view to integrate features from Java 8, according to Guillaume.
“I still see lots of enthusiasm and usage,” he says, when Alex asks how it compares to a year ago. “It’s still doing really great.”
Moving on to Grails, Alex asks Graeme what additional benefits are derived from Grails being built on top of Spring Boot. The major one, says Graeme, is complete access to all of Spring Cloud, which provides for annotating applications created in Grails 3.0 with all of the Spring Cloud annotations. “A Grails 3.0 application can participate as a backend service or a frontend service within your existing Spring Cloud infrastructure,” he says.
Grails 3.1 will include alternative profiles for creating REST API-style applications serving JSON reponses. “When you create what we call a ‘web API application,’ you get a different set of co-generation commands, a different set of plugins, completely tailored at creating REST APIs, and improving the developer experience in creating those APIs,” says Graeme.
Grails 3.1 will also include support for Hibernate 5.o and Mongo db3 Driver. “We’re pretty excited for a new profile that we’re planning on developing for smaller backend REST microservices that will be based upon Netty and asynchronous non-blocking reactive applications,” he continues.
“We have a very clear idea of where we want to go in terms of reactive applications with Grails in 2016,” says Graeme.
To wrap up the session, Alex and James elaborate on the topic of cloud native. Before he and Alex re-visit the Netflix-Pivotal collaboration, and also take on design for failure, James reflects on his message to enterprise customers.
“They’re stuggling with operational complexity,” says James. “They’re trying to now move to a DevOps model where they’re continuously delivering new code, and what stops them from doing that is this operationally complex culture they have, because they’re all there to make things move slower and to heal things.”
“Cloud native is what enables you to have that almost zero-touch operational culture that finally lets developers just continuously deliver code.”
Pivotal is a sponsor of The New Stack.