Apple announced the first Developer Preview of Swift 3.0 at its annual Worldwide Developer Conference in San Francisco (WWDC) this week, marking the next phase in the rapid evolution of this increasingly popular open-source programming language. The growth of the Swift ecosystem among third-party developers is something of a phenomenon, and IBM appears to be leading that burgeoning pack.
Since Apple released the language to open source last December, Big Blue has become one of the largest users of Swift for mobile app development. It was the first cloud provider to enable the development of applications in native Swift. The company likes to say it was "first to the table" with Apple to bring Swift to the enterprise. "We jumped in full-force in December," said John Ponzo, an IBM fellow and vice president and CTO of IBM's MobileFirst group. "We saw the potential right away to move this out to the server. We were all in right away."
To date, IBM has built more than 100 enterprise applications using Swift, and it has developed a range of tools for the language -- things like the newly announced IBM Cloud Tools for Swift (ICT), which is aimed at developers creating Swift apps "that span both client and server-side code." ICT is a Mac app designed to simplify the management and deployment of server-side assets, Ponzo explained. It allows developers to group client-side and server-side code written in Swift, deploy the server-side code to IBM's Bluemix cloud platform, and then manage projects using ICT.
Ponzo also pointed to the success of IBM's Swift Sandbox, a cloud environment that allows devs to write Swift code and execute it in a server environment on top of Linux. Each sandbox runs on IBM Cloud in a Docker container.
The company claims more than 1.5 million code runs on the Sandbox, up 200 percent since February.
IBM also announced Swift 3.0 beta on LinuxONE, IBM's Linux-based mainframe servers. Developers are now able to use Swift on LinuxONE, Ponzo said. The company plans to have a production-ready release when Swift 3.0 goes GA.
IBM sees great potential in Swift on the server side, Ponzo said. The company has been focusing its efforts on maturing the language at the backend and adding "first-class support" in the cloud. "This is really about addressing the key issues that enterprise developers are having," he said. "Swift has this combination of scripting-language-like syntax with a core systems language, and we're looking at how it can help developers who are building the next generation of cloud-based workloads. We'd like to make Swift a very big part of how those next generation services are built."
Big Blue also claims more than 1,500 client and server-side packages on the IBM Swift Package Catalog (up 400 percent since February), and more than 100 apps across 14 industries built on the IBM MobileFirst for iOS solution, which combines IBM's data and analytics with Apple's consumer experience.
Back in February, IBM introduced Kitura, an open source Web framework, written in Swift, that enables both the mobile front-end and back-end portions of an application to be written in the same language.
Launched at the 2014 WWDC, Swift is the successor to Apple's Objective-C. It sheds the "baggage of Objective-C," the company said at the time, to provide "an innovative new way of coding for Cocoa and Cocoa Touch." Where Objective-C relied on defined pointers, the Swift compiler infers the variable type. But it kept such features as well-defined namespaces, generics and operator overloading.
Posted by John K. Waters on June 15, 20160 comments
Hewlett Packard Enterprise (HPE) is inviting open source developers to write and contribute code to The Machine project, an effort to juice up its ambitious plan to reinvent computing. During my reporting on that news I had the opportunity to talk with a real veteran of the Open Source Wars. (Not officially a thing, I know, but it should be.)
Bdale Garbee, HPE Fellow and Office of the CTO at Hewlett Packard Labs, has been involved with open source software professionally since the early 1990s. He was one of the first Debian developers, and set up the original developer machine for that open source OS in 1995. Garbee said he actually made his first contribution to what would later be called free and open source software (FOSS) in 1979. He has been continuously involved ever since.
Garbee had been working at HP for 26 years when he took early retirement from his job as Chief Technologist for Linux and Open Source in 2012. He was called out of retirement in late 2014 by Martin Fink, EVP, CTO and Director of Hewlett Packard Labs. Garbee agreed to come back and help with The Machine in no small part because of Fink's reputation as an exec who gets open source.
"He twisted my arm to come back, because he saw that there was an opportunity to grow the company's open-source strategy into a major pillar of its general technology, development, and evolution strategy," Garbee said. "We're now working with others inside the company, thinking about our future technology roadmap and our development activities as an opportunity to be more open and collaborative by default."
Of course, nowadays everybody gets open source. During one of his first conference keynotes, Microsoft's newish CEO, Satya Nadella, famously declared "Microsoft loves Linux!" But HPE opened The Machine much earlier in that project's lifecycle than is typical, and Garbee expects that to happen more often at HPE. And HP has been involved in the open source world for decades, chiefly around the Linux kernel, but also as a big contributor to OpenStack and other projects.
"Somewhere between the time I took early retirement and when Martin brought me back, we turned a corner," Garbee said. "It's just different today. I'm no longer beating on people's doors to get them to open up and listen. It's very much the other way around. It's no longer a question of whether open source is a good idea. It's all about finding the right way to structure the work and build communities of interest around the pieces of technology and the work that are most interesting to us."
"I've had this conversation with some of my peers in the industry who have also been involved with free and open source for a very long time, where we look at each other and say, 'Oh my god, we won! Now what?'" Garbee added. "It's immensely satisfying, but the stress level does go up a bit. We've convinced everybody that these are good ideas. We've shown the world that you can run successful businesses around this model of collaborative development. HPE is making what amount to company sized bets on doing things this way. We definitely have to deliver. We have to make it all work."
BTW: "Bdale" is a non-punctuated contraction of "Barksdale," Garbee told me, which was his maternal grandfather's last name. His full name: Alfred Dickenson Barksdale Garbee II.
Posted by John K. Waters on June 13, 20160 comments
Oracle's decision to shut down the java.net and kenai.com collaborative Web sites by next April has the Java community -- especially the Java EE community -- buzzing. The company announced plans last year to move the content and services of Kenai to java.net, but now says both portals will be "sunsetting" on April 28, 2017.
Java EE evangelist Reza Rahman, in a letter to members of the Java EE Guardians, called the decision "tragic," and "very troubling for Java EE."
"The problem is that Java EE JSRs and GlassFish itself is heavily reliant on java.net," Rahman wrote. "Oracle so far has not announced a transition plan and is basically asking everyone with java.net projects to do any migration on their own. This is especially troubling since our current projections show Java EE 8 scoped work is highly unlikely to be delivered by April 2017 -- which raises the question of how Java EE 8 will be delivered at all."
Oracle moved the so-called community content of the sites to the community.oracle.com Web site last fall, and insists that this portal will be a "much better platform for collaboration" because of new spaces provided for Java Champions, Java User Group (JUG) leaders, and the Java Community Process (JC). But for future code collaboration, Oracle is pointing developers to other social coding platforms.
"As for the forge half of the site, there has been a tremendous amount of innovation in the code collaboration space, and developers have migrated to a small set of very popular platforms like GitHub," the company said in a statement. "In light of this, we felt we could contribute more value to the community through other programs and by investing in GitHub, because our community is increasingly active there."
The Java community has been talking about the shortcomings of java.net for some time, but what some see as the abrupt termination of these two portals has been unsettling.
Ondrej Mihályi, a Java EE trainer, consultant and senior services engineer at Payara Services in the Czech Republic, allows that java.net and Kenai haven't kept up with modern trends. It makes sense for Oracle to reconsider their roles in the Java ecosystem, he said in an e-mail, but the abruptness of the shutdown announcement makes him question the company's motives.
"The way Oracle announced the plan to shut them down makes many members of the community wonder whether it was carefully planned or just a desire to cut costs and shut down projects they cannot monetize," he said. "The latter is more likely, as even many people from Oracle, who stand behind existing projects hosted on java.net, don't yet have a plan how to migrate their projects to somewhere else."
Oracle underestimates the value of these collaboration platforms for growing community involvement, Mihályi said, and perhaps the value of community involvement itself.
"There are many valuable resources on both java.net and kenai.com, including project sources and documentation, forums, blogs, and other sorts of information, such as JUG profiles and documents," he said. "[Oracle's decision] poses high risk that a certain amount of that information will be lost after the shutdown of both sites. We can remember the losses from recent history, when all sun.com sites were migrated under Oracle domains, but not all links are properly redirected to date. They say the Internet has very good memory, but it can also forget badly when a site goes down completely."
Werner Keil, DevOps Build Manager at Visteon Corp., is a member of the JCP Executive Committee, spec lead on JSR 363 and an Apache committer. He likens Oracle's decision to shutdown the forge sites with its decision to enfold the JavaOne developer conference within its own OpenWorld event.
"The Java community becomes less visible in a giant pool of various products and technologies from Oracle DB to Fusion Middleware or Siebel, just to name a few," he said in an e-mail. Fully assimilating Java as a product rather than supporting an open, community-based project is "consistent with Oracle's approach," he said.
"As other portals (for example, Google Code) faced before, it seems, Oracle wants to save the cost of maintaining its own separate forge and project hosting for Java," he said.
Both Werner and Mihályi are members of the Java EE Guardians, an independent, volunteer advocacy group formed a few months ago to support enterprise Java. Mihályi sees the java.net shutdown as especially threating to Java EE.
"The important fact to point out here is that java.net has been a standard place to host all the official resources for most Java EE JSRs, including project sites, history of public communication on mailing lists, tracked issues, sources of the reference implementations," he said. "If java.net was shut down right now, it would practically mean death to Java EE, or in a better case, a hibernation lasting for many months. We as Java EE Guardians intend to keep reminding this fact to Oracle, the JCP board, and JSR specification leads and actively offering our cooperation in finding a new home and in migration for all JSRs and related projects. We certainly want to make sure that no valuable resources are lost and that the new tools and hosting is even more appropriate than current solutions."
"In the end," he added, "if we are successful, we can all benefit from making the Java EE process more transparent and accessible to an even wider community. There is always a room for improvement in the Java EE JSR processes (licensing issues, accessibility to TCKs and certifications -- just to name a few). And we all hope that we are able to contribute to overall openness of the platform in order to foster cooperation and standardization."
Posted by John K. Waters on June 8, 20160 comments
The recent decision by a federal district court jury that Google's use of 37 Java APIs in the development of its Android OS was a "fair use" of that technology and did not infringe on Oracle-owned copyrights came as a relief to the developer community, generally speaking, if a temporary one. The reaction of Josh Juneau, a Chicago-based app developer, blogger and author, was typical:
"I think this is a win for the developer community," Juneau said in an e-mail. "APIs are different from fully functional and completed applications or products. Many of us developers utilize open sourced APIs every day, and it would be a huge burden if we had to worry about licensing, etc. That is one of the reasons we use and develop open source software: so that others can make use of it as they see fit."
Gartner analyst Mark Driver has been a vocal critic of "the absurdity of Oracle's case" for some time. He reiterated his position in an e-mail that "copyrighting APIs is ridiculous and threatens innovation across the entire industry." He doesn't love the fair use argument, but he allows that it effectively addresses the mistake the court made with the earlier decision.
Oracle is going to appeal the latest decision, of course, so this story -- this long, long story -- has a few chapters left. But in the telling of it, says former Oracle Java EE community evangelist Reza Rahman, a larger point is being lost.
"I think both sides in this case are wrong," Rahman told me, "because neither side is serving the interests of developers."
Rahman, as we reported earlier, was the driving force behind the recently formed Java EE Guardians, a group of volunteers committed to supporting enterprise Java. He left Oracle earlier this year and now works as a consultant with CapTech Consulting.
"These guys should be working together and providing a standard API that Java developers can rely on without having to hitch their wagons to either Oracle or Google," Rahman said. "That would be the right thing to do. That's what Sun Microsystems wanted to do when it was the steward of Java. And that's what these two companies would be doing if they truly cared about developers. I see only self interest in all of this."
But Rahman has what I would call mixed feelings about the copyrightability of APIs.
"If I create an API, it should be within my rights to copyright it," he said. "Fair use, which is always judged on a case-by-case basis, acknowledges that sometimes there's a greater purpose than that served by copyright, and that should be accommodated also. In a perfect world there is no IP, and yet, when you create value you should be able to monetize that. This as a very slippery slope we're on right now."
To be clear, U.S. District Judge William Alsup's original ruling that the Java APIs at the center of the lawsuit were not subject to copyright was overturned on appeal, and the U.S. Supreme Court refused to hear Google's appeal, which effectively means that APIs are copyrightable. Historically, APIs have not been protected by copyright, but Oracle has argued that the "structure, sequence and organization" of the API packages in Java are sufficiently complex to merit protection.
"It's time to leave the bickering and uncertainty that has been hovering over the Java community behind," Rahman added, "and let's arrive at an API that moves the standard forward."
Amen to that.
Posted by John K. Waters on June 6, 20160 comments
Containers offer a number of advantages over traditional virtualization software, but easy visibility isn't one of them. Modern modular application architecture has, in fact, created a kind of "black hole" of complexity swarming with packages and dependencies developers can't readily sort out.
It's no surprise to see a growing number of container scanning products emerge to address this problem, but the latest entry into this market, JFrog's newly announced Xray, promises unprecedented visibility into the contents of software components, which the company calls "radical transparency."
JFrog CEO Shlomi Ben Haim described his company's fourth major product release as a one-of-a-kind tool that will give organizations an unparalleled level of understanding about all their container images, software packages and binary artifacts.
"Xray will not only tell you that you have a security vulnerability or a licensing issue," he told ADTmag, "it will also provide you will a full graph of all dependencies. It tells you where you are exposed and how your Ops environment is suffering from this specific software package. You have the chance to zoom in and magnify a vulnerability, security, or license issue and put things on hold before blessing a production environment."
Xray's ability to provide this kind of impact analysis is the product's key differentiator, Ben Haim said.
A fully automated platform, JFrog Xray comes with a REST API that supports integration and automation with an organization's continuous integration and continuous delivery (CI/CD) pipeline, and allows other inspection and security tools to fit into the full build-to-production automated flow, Ben Haim said
It also includes notification technology from VersionEye, a Mannheim, Germany-based start-up that provides a system for tracking open source libraries and alerting developers in real time to security vulnerabilities, license violations and outdated dependencies. VersionEye technology monitors more than a million open source projects on a daily basis, said company founder and CEO, Robert Reiz, in a statement.
"Integrating the VersionEye technology with the JFrog platform creates an unparalleled capability for deep understanding of the quality and provenance of the software components organizations depend on," Reiz said.
The tool also integrates with other vulnerability and license compliance databases, such as Black Duck and WhiteSource.
Xray integrates tightly with JFrog's binary repository manager, Artifactory, which stores binary artifacts and the metadata that describes them in a defined directory structure. Artifactory was one of the first cloud-based binary repository managers. The company also makes Bintray, a distribution-as-a-service (DaaS) platform designed to give development organizations full control over how they store, publish, download, promote and distribute their software.
The software management and distribution tools provider unveiled Xray at its annual swampUP user conference, under way this week in Napa, Calif. The company also announced at the show the availability of Artifactory running as a SaaS application on the Google Cloud Platform, as well as a collaboration with Atlassian to integrate that company's Bitbucket cloud-based DVCS hosting service and the JFrog platform.
JFrog expects to ship Xray in early Q3.
Posted by John K. Waters on May 24, 20160 comments
Much of the press around this year's Google I/O event focused on the company's day-one consumer app-economy announcements, but there was plenty of news for enterprise developers in the opening keynote.
The most immediately relevant announcement was the launch of Preview 1 of Android Studio 2.2. The upcoming version of the official IDE for Android app development includes a rewritten layout designer, an automated test recorder, a Firebase plug-in, and the latest updates of JetBrains' IntelliJ IDEA and CLion development environments, on which the IDE is based.
The most welcome upgrade (judging from the applause the announcement received) is the new test recorder feature. Based on the Expresso testing framework provided by the Android Testing Support Library, the new tool allows devs to test an app manually while recording the interactions in Espresso code. That code can be played back across a number of platforms, including Google's Cloud Test Lab, to re-test the UI over and over again.
The new layout designer also drew its share of oohs and aahs from the crowd. Designing the UI for an Android app can be challenging, given the variety of screen sizes and resolutions the developer must accommodate. The rewritten designer calculates the screen positioning and sizing (constraints), which means the UIs can resize automatically for different screens.
Android Studio 2.2 also introduces support for the NDK-Build and Cmake build tools used for creating C++-based apps.
Versions of Android Studio 2.2 for Windows, Mac, and Linux can be downloaded now from the Canary Channel Page.
Google also announced that it will be adding features to its Firebase back-end-as-a-service product, which it acquired in 2014. The company plans to integrate Firebase fully with its existing products and services, and says that many previously paid-for features, such as Cloud Messaging, will be free going forward. The new Firebase is a single SDK that provides analytics, remote config, crash reporting, test lab, notifications, dynamic links, invites, AdWords and AdMobs. One notable new feature, Crash Reporting, provides reports to help diagnose and fix problems that show up in Android or iOS apps. The feature is based on Firebase Analytics, which allows developers to see information about how and where an app is being used.
The company also made several announcements around the third (and probably last) preview release of Android N. This version of the OS is shaping up to be very VR-centric, with support for the new Daydream system, announced at the show. The new OS will also support the advanced Vulkan graphics API, and and bring split-screen multitasking and picture-in-picture video playback. And there's a new JIT compiler designed to improve performance and take up less storage space.
The "N" in Android N is just a placeholder, of course, and Google has invited the public to help name the next version. ("Namey McNameface" has been disqualified as a potential option.) I'm guessing they'll be looking for something sweet, given the previous naming scheme. For what it's worth, I'd go retro with something like Abba-Zaba or Pop Rocks.
Posted by John K. Waters on May 19, 20160 comments
The Java EE Guardians this week unveiled a public draft of their charter, and it's worth reading for anyone interested in the future of enterprise Java. The charter makes and supports the argument that Java Enterprise Edition (Java EE) continues to be essential to the long-term health of the Java ecosystem, and then it lays out compelling evidence that Oracle is "conspicuously neglecting Java EE."
A big chunk of that evidence comes from data analysis conducted independently by Josh Juneau, a Chicago-based app developer and author. (He wrote JavaServer Faces: Introduction by Example and Java EE 7 Recipes.) Earlier this year, Juneau began tracking "a decline in activity" around Java Specification Requests (JSRs) aimed at Java EE 8 for which Oracle maintains the lead.
"I had noticed activity declining late last year, but it wasn't until other members of the community pinged me in January to express serious concerns about a slowdown they were seeing that I really sat up and took a hard look," Juneau told me. "That's when I saw a clear drop in activity on these JSRs starting back in October. And then I started compiling the numbers."
Juneau chronicled his analysis in a long blog post that I highly recommend. He focused on JSR 372: JavaServer Faces 2.3; and JSR 368: Java Message Service 2.1. Juneau serves on the expert group for JSR 372 and JSR 378: Portlet 3.0 Bridge for JavaServer Faces 2.2. Many of the charts he included in that blog post to illustrate his findings appear in the Guardians' charter document.
"It seems as though Oracle may be shifting direction with their enterprise technology toward microservices and the cloud," Juneau said, "which is the way things are going nowadays. The problem with that strategy is that most of the ecosystem for the cloud, and even microservices, relies completely on Java EE technology. This really should be a concern to the Java developer community as a whole."
The Java EE Guardians, a group of volunteers committed to securing the continuing evolution of enterprise Java, formally announced their organization in March, though many of the group's members had been meeting for several months over concerns about Oracle's seeming lack of commitment to the upcoming Java EE 8 release.
Juneau has been a part of that conversation for some time, and he joined the Guardians to continue it at another level, he explained. "I guess my primary goal is to get a clear answer from Oracle about the future of Java," he said. "And if it turns out that Oracle isn't interested in helping to evolve those JSRs that are a part of Java EE 8, I'd like to explore the possibility of seeing those opened up so that the community and other organizations can take them over and move them forward, because they are so important to the entire ecosystem."
At least some of the heat that sparked the formation of the Guardians was generated when the head of Oracle's Java EE group, senior vice president Cameron Purdy, left last year amid rumors that Oracle was thinning its Java evangelist ranks. Other Java execs followed, including Reza Rahman, a former Oracle Java EE community evangelist who has been something of a driving force behind the Guardians.
I think it's worth noting that Juneau, Rahman, and all the Guardians I've spoken with to date give Oracle credit for being a good shepherd of Java over most of the past five years, and applaud the work of of the Oracle spec leads in general. (Juneau gave a shoutout in his blog post to the spec leads for JSR 372.) Their current concerns, they have said, arise from recent developments.
The Java EE Guardians maintain a public Google Group for open discussions of their concerns and activities. And they post regularly to Twitter with the handle @javaee_guardians.
Posted by John K. Waters on May 6, 20160 comments
It's official: Jenkins 2.0 has arrived. Available today, this is the first major release of the open source continuous integration (CI) server in 10 years, and the excitement surrounding it is palpable. (Sorry, that was my Apple Watch telling me to stand up -- again.)
But seriously, this truly is an event. After 655 weekly releases, the once-controversial CI server has evolved into a continuous integration/continuous delivery (CI/CD) system that provides a flexible way to model, orchestrate and visualize the entire software delivery pipeline.
"Pipeline" is the key word here -- or rather "pipeline-as-code." With this release comes the first officially supported implementation of a domain-specific language (DSL) for the coding of pipelines for continuous delivery. The new Pipeline plug-in is designed to help Jenkins users model their software delivery pipelines as code that can be checked in and version-controlled along with the rest of their project's source code.
"Probably one of the most important changes in this release is that Jenkins can now understand and model a delivery pipeline, natively, which it couldn't do before," Jenkins community leader Tyler Croy told me last week. "For me as a practitioner and Jenkins administrator, the out-of-the-box defaults we've changed in this release are also important, especially for new users. New users of Jenkins are going to find it much easier to get set up with the tools they need, and Jenkins will be more secure out of the box."
Croy is a Jenkins evangelist and community manager at CloudBees (the chief commercial supporter of Jenkins), which means he gets to work on Jenkins full time. He's been a leader in this community since before the fork from Hudson, so he's seen most of its evolution. He told me that, among other things, Jenkins 2.0 represents some fundamental rethinking at CloudBees -- and by Jenkins creator Kohsuke Kawaguchi -- about how the CI/CD server is going to be developed going forward.
"This was the first time we've had a parallel branch of development -- literally, on Git -- to work on big features," Croy told me. "Kohsuke has been a big proponent of the agile development concept and getting changes out to users as quickly as possible and getting feedback. But it's been hard to step outside that release process and think about bigger initiatives we could tackle to improve Jenkins over the next five to 10 years. Incorporating some of the UI changes and improving the getting-started setup to make the out-of-the-box experience better, for example, were things we developed over the past five or six months in parallel with the weekly release cycle. We have the ability now to experiment, try new things, and take on bigger initiatives that are challenging and time consuming in that separated little space of Jenkins development."
Storage plugability improvements are at the top of the community's to-do list, Croy said. No committers to anything yet, but this is the type of project that can now be accommodated by this parallel Jenkins development process for bigger releases.
Continuous integration has almost become a default in the standard software development stack, Croy observed, and continuous delivery is heading in that direction, too.
"There was a time when source control management wasn't part of the stack," he said. "Now it's standard to use Git or Subversion, and if you don't, people look at you like you're crazy. The same is true now for CI, and the direction the industry is moving tells me that CD is going to become standard part of that stack, too. People are saying, great, you can build and test your software, but how do you deliver it to your customers? It's just a matter of time before CD is standard in the stack, too."
"My personal goal," Croy added, "is to make Jenkins vastly more usable and much better documented and easier to adopt by 2016. This is something that we've started to do in Jenkins 2.0, and I plan to continue focusing on that comprehensive user experience."
A detailed overview of the Jenkins 2.0 release is available on the Jenkins Web site. And there's some great documentation ("Getting Started with Pipeline") online.
Posted by John K. Waters on April 26, 20160 comments
The big news in the evolving container ecosystem this past week was Mesosphere's announcement that it will be open sourcing its flagship Data Center Operating System, rebranded as DC/OS. (The company will also offer a commercial Enterprise version.) Among the long list of companies partnering with Mesosphere on DC/OS beta is a startup called Avi Networks, which got my attention at the Container World 2016 conference.
Started by former Cisco execs, the Sunnyvale, Calif.-based company emerged from stealth mode in December 2014 with the aim of delivering an application services platform fully implemented in software. The Avi Vantage Platform provides an alternative to legacy application delivery controllers (ADCs). It comprises the Avi Controller and distributed "elastic micro-ADCs" called Avi Service Engines, which are distributed across the environment to deliver services close to the applications. The platform's virtual engines perform Layer 4-7 functions (transport, session, presentation, application), which puts the company in competition with such established providers as F5 Networks, Citrix Systems, A10 Networks and Radware. Avi execs announced the integration of the Vantage Platform with Mesosphere's then-commercial-only DCOS at the Container World conference.
I had a chance to talk with Avi's CEO, Amit Pandey, about his company and its efforts to modernize application services. Pandey, who has been working around the Layer 4-7 space since 1998, said he has seen very little change in the architecture of the upper layers of the OSI model.
"It sits so close to the application that it's really surprising changes haven't happened," Pandey said, "because the fundamental way applications are build and deployed have changed dramatically. We've gone through a couple of generations of change, in fact. We had three-tier applications, then the onset of virtualization led to significant changes, especially in the way apps were deployed, and more recently we have microservices, which fundamentally changes the architecture and the tools for building and deploying applications. And through all this change, the ADC has just sort of chugged along. It's a very sleepy industry."
Avi's founders, Umesh Mahajan, Murali Basavaiah and Ranga Rajagopalan, decided to wake up that sleepy industry with an architecture that mimics a software-defined networking (SDN) architecture, Pandey said, resulting in what amounts to software-defined ADCs and load balancing. But the founders also recognized that, to accommodate things like microservices, containers, and public clouds, the architecture would have to be distributed, with a centralized control plane, and the ability to, essentially, learn about deployments and traffic patterns and bring that learning back in a kind of feedback loop to facilitate things like elastic scaleout, remediation against attacks, and/or giving developers the ability to troubleshoot microservices.
"In this brave new world of modern applications, we need the ability to control and manage highly distributed architectures; to manage multiple clouds; and to give analytics, visibility, and feedback for a high level of elasticity," Pandey said.
In a nutshell, Avi is providing appdev teams with a software-defined system that delivers discovery, security, and load balancing services elastically, with centralized control and monitoring. And Avi's layer of infrastructure is so application-like it can be put into a container and deployed almost anywhere. "Our customers often tell us that we are more like an application than infrastructure," Pandey said. And that's really what our vision of networking infrastructure is. It should be part of your app, because then the level of visibility and flexibility you have is phenomenal. Why should your network services be a distinct and inflexible hardware box when you can actually containerize it?"
Posted by John K. Waters on April 25, 20160 comments