NGINX Product Roadmap 2017

NGINX Product Roadmap 2017

This post is adapted from the keynote by Owen Garrett, Head of Products of NGINX, Inc. at nginx.conf 2017. Watch the talk, NGINX Product Roadmap 2017, on the NGINX YouTube Channel.

Thank you for the warm welcome. It’s fantastic to be here. It’s our fourth user conference, and this one, I promise you, is going to be the most important, the most significant, and the most exciting when it comes to product announcements and what’s going on in the engineering and product teams at NGINX.

First, let me share with you a little story about disruption to help you understand why it’s important, and why it creates so many fantastic opportunities for all of us. I love traveling, and last weekend, I spent some time in Detroit and went to the Henry Ford Museum, dubbed the Museum of American Innovation.

It was inspiring, wandering around, seeing the industrial machinery from the turn of the last century, and it kind of hammered a point home about electricity, and how that disrupted American manufacturing.

Electric light bulbs were commonplace by 1880. There were generating stations in New York and London by 1881, and municipal stations in all major Western cities in the years shortly afterwards.

But electricity took a long time to permeate into manufacturing and industry. You’d have thought that an industry would’ve jumped on the opportunities that electricity created, but it couldn’t.

The problem was that manufacturing was based around the steam engine. A large, monolithic steam engine at the corner of the factory drove every single bit of machinery. Gear cutters, punches, lathes, and drivers were all attached to one huge, big, shaft running through the factory, attached by pulleys and gears and other shafts, and the factory danced to the tune of that steam engine. It was an impediment to innovation.

And, firstly, some forward-looking industrialists swapped out the steam engine and put an electric motor in its place  – cleaner, more efficient, but almost no effect on productivity. What we learned from that is that successful disruption needs more than just a technology swap.

It took 40 years for American manufacturing to fully realize the benefits of electricity, going from a monolithic steam engine that defines every single process in the factory through to micro-electric engines  – electric motors  – each individual bit of machinery with its own electric motor.

What that allowed the industrialists to do was to begin to re-platform their factory. They could move machinery around. They could make production lines that matched what they were trying to manufacture, not dictated by the steam engine and the infrastructure. It took 40 years for that transition to take place.

It’s a little bit different for us. The barriers are much lower for us. We’re not dictated and held back by hardware; we’re software. The disruptions that are coming on us wave after wave  – containers, virtualization, Kubernetes, microservices, architectural changes  – all of these create opportunities for us, and it’s a really exciting time for us to be in the industry.

The disruptors often have one thing in common. The most successful disruptors are using NGINX:

• Adobe, building a high-performance API gateway, so that they can take their classic desktop applications and make those available to more users
• Dropbox, revolutionizing file sharing; they’re using NGINX to build edge caches and accelerators to get their content to their users faster and more efficiently
• Equifax, using NGINX in a rich CI/CD-driven environment, so they can bring new innovations and new features to their users faster and faster and faster

These three companies  – close partners of ours  – are all here at the conference; they’re all presenting. I can heartily recommend the sessions that they’ll be holding.

And NGINX is at the heart of almost every disruptive initiative today; these organizations, and many more.

How do we know this? How can we claim that NGINX is one of the engines driving modern disruption? We look at the numbers.

Over the last five years, innovators, people who are building successful and busy websites and applications, are choosing NGINX. And there’s been a transition: five years ago, NGINX was the most popular platform for the small minority of the 1,000 busiest websites in the world.

And then the message began to spread: a year after, the most popular platform for the 10,000 busiest websites in the world.

Two years ago, the most popular for the 100,000 busiest websites in the world.

And you can see where we’re going: just 10 days ago, in their latest figures, W3Techs showed that, finally, NGINX is the platform of choice for the million busiest websites in the world.

The lesson is: if you are planning to build a busy, successful, innovative, market-leading website, there’s only one choice. And it’s not just for ingress traffic, north-south traffic, stuff coming in, load balancing. For years, ever since we produced the official NGINX repo on Docker Hub, it rocketed to the top of the charts.

The NGINX official repo, managed by our team, is the number one starred, the number one pulled container image from Docker Hub: a fantastic fit for modern, innovative, forward-looking environments.

But, as the industrialists learned, a technology swap alone is not enough.

You also need to innovate at the speed of software  – change the way that you build, measure, and deliver applications from a risk-averse approach, where you measure the success by uptime, through to a much more forward-looking dynamic approach.

Or you innovate and you measure your success by time to fix Or you innovate and you measure your success by time to fix  – measure your success on how quickly you can respond to issues that happen in production, as your business is moving faster and faster and faster. Don’t measure scalability just by “can I handle 100,00 users,” or “a million users.”

You need to measure your scalability on the rate of change of your application on your infrastructure, the size of your application, and the number of applications and services that you’re delivering.

You need tools that give you the freedom to innovate safely in your development, in your staging, and, let’s be honest, in your production environment. It’s absolutely vital that you have a software platform that you can trust, that gives you that freedom, but doesn’t compromise the quality of delivery of your applications.

NGINX has been with you through that journey. We built NGINX to embody the best practices in application delivery. We learned from the early adopters  – the Netflixes, the Facebooks, the Hulus; the companies who are handling huge volumes of traffic, embracing new technologies and new approaches.

We took the learning from there, and we folded that back into NGINX and into NGINX Plus. For example, we learned from the ways that organizations built up open source application delivery tiers, and we coalesced those together into a single software platform: NGINX Plus.

There are some great announcements to share with you today. We’re announcing official support for an Ingress controller solution that allows you to run NGINX and NGINX Plus and deliver traffic on Kubernetes and Red Hat Openshift platforms. Come and see the session later today with my colleague, Michael Pleshakov, the author and the brains behind that project.

We’re building solutions on Service Data Objects (SDO) as well, looking at the disruption and the innovation in the market. We’re looking at the ways that SDO is enabling organizations to build responsive service mesh-based applications, and we have a project in place to embed NGINX right within that ecosystem.

Come and find AJ Hunyady at a session later today. He and Sehyo Chang, behind the project, will run through what we’re doing and give you a demo of where we are now. And there’s plenty more that we’ll be announcing over the next couple of days.

What we learn, as we talk to our customers and our users, is that there’s a very common use case for the NGINX technology, and it generally centers around two different initiatives that people are trying to run in parallel. They’re seeking to re-platform their application. They’re moving left to right through this chart, going from web monolithic or multi-tiered through to cloud-native approaches.

At the same time, they’re seeking to re-platform their platform, moving from a physical, or on-premise, or colocated data center through to a cloud-powered data center, and bringing in technology like containers to help facilitate all of those changes.

NGINX and NGINX Plus provide a consistent and reliable front end, so as you change and morph the application, NGINX and NGINX Plus can ensure that it’s delivered in a standard and consistent fashion, so that users aren’t aware of the changes behind the scenes. They can continue to access the services without any interruption.

But as you go through these changes, the challenges that you face go much deeper than what can be solved and what is delivered by the reverse proxy in front of the application. Every new architecture, as we go through this 20-year cycle of changes, requires new tooling to support the architecture and make the most of it.

What we’d like to do today is announce two really exciting new initiatives. This is a really big moment for NGINX. I promised you: this is our biggest products announcement, the biggest conf yet. The first initiative was started by Igor Sysoev. Igor, the founder of NGINX, the author of the NGINX project on working NGINX Plus, had an itch to scratch.

He had some new ideas he wanted to embody, and for the last five or six years, Igor has been working on some new approaches on how to build a truly modern application and delivery platform. So there’s one coming.

And then  – hands up  – who recalls the company called Zokets who were on-stage with us last year? Zokets demoed an integration between the cloud platform  – anyone remember that container provisioning platform?  – and our microservices architecture. We were inspired and enthused by what they managed to do in such a short period of time.

We loved their technology. We loved their team. They liked NGINX. We got together. And that partnership acquisition, full merger, has brought about the next big change at NGINX. Are you ready for what we’ve got coming up? Yep? Okay.

Number one: I love this one, NGINX Unit. NGINX Unit, Igor’s project, is a next-generation server for cloud-native applications. Why, you ask? Why, Owen, does the world need a new application server? There are hundreds of them out there already.

Here are three reasons for you to consider why we need a new application server:

1. Cloud-native applications are multi-language and multi-platform. They encourage every development team to use their own technology of their own stack, which is brilliant for developer productivity, but, as most of you guys are Operations, you know the challenges that causes, managing multiple different stacks, even different versions of the same stack in production; deploying, monitoring, updating  – challenge one.
2. Challenge two: all of these application servers are hard to control. Not only do they all have different interfaces to manage them, but the interfaces are rooted in the way that things were built 20 years ago. They’re driven by configuration files. They require hard restarts. They’re not agile.
3. And thirdly, perhaps the biggest challenge for modern cloud-native applications is the networking. How do you connect this distributed application together in a way that’s reliable, scalable, and responsive to the needs of the application?

This is what we’re addressing with NGINX Unit, an open source application platform server from NGINX. NGINX Unit is small, it’s lightweight, it’s fast, and it supports multiple languages from the same software platform. You can build a container with Unit inside and that container can run your code in PHP, or it can run your code in Python, or it can run your code in Go, or it can run all three at the same time with multiple versions of each language  – if that’s what you need. It’s a single consistent platform, however you build your applications.

It has a REST API driven with JSON configuration and minimal config files. That makes it truly dynamic. On a dynamic all the way through, configuration changes made through the REST API are done in memory with minimal restarts or reloads.

And we’re building out a native reverse proxy and load balancing layer within Unit, working with the service discovery mechanisms so that Unit will cluster and build its own service mesh.

Unit is available, launched today, as a public beta. It’s been running with private betas for a couple of our users over the last couple of months, and we have a long, ongoing roadmap of features.
We’re going to go into Unit in a lot more detail tomorrow as part of our open source keynote. Igor will talk through some of the design decisions, the smart architecture in Unit, so I’ll leave it hanging there. What I’d like to do is move on to our next project: NGINX Controller.

NGINX Controller, built out of the Zokets technology, is the mission control for your modern web application. It deals with the question: how do you scalably, reliably, and reproducibly perform the kind of DevOps operations that you need to manage your application?

Our tenet is that there are no enterprise-grade solutions available today that span the gamut from monolith to microservices, from physical to cloud, that can manage these processes for you without impacting your business. And the alternative, now, is that you need to build a lot of custom tooling  – tooling that’s expensive to develop, it’s error-prone, it’s difficult to maintain, it’s challenging to scale.

Our goal with Controller is to help you manage that complexity as you go through the journey from a monolith to a modern, dynamic application environment. At its core will be a degree of intelligent policy control and workflow automation.

Why? Because we’ve learned that one of the biggest challenges that you face is industrializing the right, best practice in a reliable, repeatable fashion that recovers from errors and unexpected events without affecting the availability of your live application.

A controller begins with this degree of automation and control. It implements it with configuration and fleet management and then fills that out with advanced monitoring and advanced analytics so it can inform those processes.

It satisfies the use cases that you see here, cross multi-cloud in a multi-tenant RBAC fashion with a focus on allowing you to monitor, drill down, rapidly troubleshoot issues with your application, and at the same time providing your CIO with compliance and audit trails. Controller deploys and manages fleets of NGINX proxies and NGINX Unit servers across private and public clouds.

It is the first application platform that gives you the ability to manage north-south ingress traffic and east-west internal traffic from a single interface, and allows you to go through the journey of migrating from a traditional or an existing monolith multi-tier environment to a microservice approach.

GUI, API, and CLI interfaces build and deploy these best-practice configurations. And these configurations are not just static, but will have the ability to be dynamic, driven by changes within your application.

We’re building out rich visualization, and a lot of this is in partnership with another project which we’ll share tomorrow. The visualization gives Controller a bird’s eye view of the health, the performance of your application, and will allow it to respond to unexpected behaviors. It provides the core data to drive the intelligent policy engine we’re building in Controller.

Controller is under development. Six months have gone by so far. We’ll be holding private betas in a month or two. We’re targeting our first public release for early next year. It’s a multi-year project with a very, very broad and rich vision.

But if we put this together along with the other technologies that I’ve shared with you, Controller as the management and policy platform, NGINX as the front-end application delivery tier, and NGINX Unit, this builds together to what I hope is a very, very compelling vision.

Right now, you can deploy NGINX and NGINX Plus to provide the front-end tier for managing incoming traffic, caching security, web serving, load balancing.

NGINX and soon NGINX Unit will provide you with the ideal starting point for your journey on which you can platform a traditional multi-tiered application.

Then, as you transition your architecture, you can do so on the same platform with Unit moving your approach from a monolith to a microservice approach, with a service mesh networking everything together.

On top, with a benevolent God’s eye view of everything, is NGINX Controller and the whole platform running in a platform-agnostic fashion, across cloud data centers, running in containers, running on bare metal.

Gus shared with you our vision; our vision that an application should be like a living organism. It should grow. It should evolve. It should respond to threats. It should self-heal when there’s damage. Our application platform is the technology platform that we’re building to realize that vision.

I hope you agree. It’s ambitious, but it’s a compelling vision for how modern applications can be architected, deployed, and delivered.

It’s a long journey for us  – two or more years to build out the entire vision that I’ve shared with you, but it’s a compelling journey, and it’s a journey that I hope you can take along with us.

I want to thank you. I want to encourage you to look out for the talks from some of our partners, and the talks that we‘ll be doing today about SDO, about the Ingress Controller. There’s an awful lot coming over the next two days, so please enjoy the conference, network, have fun, and I look forward to seeing you all on the floor. Thank you.

The post NGINX Product Roadmap 2017 appeared first on NGINX.

Source: NGINX Product Roadmap 2017