The committed use of a continuous delivery pipeline inevitably puts a far greater onus on the software developer than systems that used more traditional methods of moving code into product.
A DevOps approach to software development means software developers must be much more diligent in terms of the unit tests they write, and the test code coverage they provide. With continuous integration and continuous delivery, testing can no longer be an aspect of software development to which the developer simply pays lip service. A project folder containing a set of hastily written unit tests that serve little more purpose than to pass a software development audit is no longer good enough.
Due diligence and the DevOps developer
Of course, being diligent in the tests one writes is an expectation, so developers can’t complain about the rigorous requirement to do their job properly. But quick fixes and fast patches that skip the test phase are a thing of the past when CI and CD is used, as anything untested programatically that goes into production and fails points a finger directly back to the developer who didn’t thoroughly test their software. Unit tests must be well thought out, methodical and extensive.
Successful DevOps developers can take solace in the fact that the burden of assembling a continuous delivery pipleline is not one that falls entirely upon their shoulders. The tooling that has developed within the continuous delivery space is impressive. The CI tools themselves can then hook in to a variety of other tools that help move code through the software development lifecycle. The CI server can read Maven POM files in order to download required libraries and invoke Gradle scripts to perform builds. More importantly, the continuous delivery pipeline will hook into various verification tools that will run test suites. Jenkins and Hudson dominate the continuous integration server space, although there are many competitors, including Concourse CI, which are upping the ante in terms of scalability and the simplicity with which CI and CD pipelines are defined.
DevOps tooling advances
Open source tools such as JUnit and Mockito can to be called upon to run unit tests and mocks. Static code analyzers such as SonarCube or HP’s Fortify will inspect the code and flag and rate the severity of potential bugs, vulnerabilities and just general code smell. DBUnit and H2 are often called upon to stub out a database and allow integration tests to take place within an isolated environment. LoadRunner or Apache Jmeter can be used to ensure the new release can handle peak loads, and results from a performance scanning tool such as XRebel can ensure that there aren’t any outstanding performance issues that need to be addressed. When every test cycle provides the continuous delivery pipeline with a passing grade, new code gets moved into production.
But by removing all of the manual checks, and expecting every red flag to be triggered by a test that has been coded into the system, organizations embracing a DevOps based approach to software development are placing a much greater onus on the shoulders of their software developers by not only making them responsible for the code they write, but also responsible for all of the checkpoints that exist to ensure that only bug free code is put into production. It’s a heavy burden to bare, not to mention a new one for developers who have never worked in a truly DevOps based environment.
The following is a transcript of an interview between TheServerSide’s Cameron W. McKenzie and Azul Systems’ CTO Gil Tene.
Cameron McKenzie: I always like talking to Gil Tene, the CTO of Azul Systems.
Before jumping on the phone, PR reps often send me a PowerPoint of what we’re supposed to talk about. But with Tene, I always figure that if I can jump in with a quick question before he gets into the PowerPoint presentation, I can get him to answer some interesting questions that I want the answers to. He’s a technical guy and he’s prepared to get technical about Java and the JVM.
Now, the reason for our latest talk was Azul Systems’ 17.3 release of Zing, which includes an LLVM-based, code-named Falcon, just-in-time compiler. Apparently, it’s incredibly fast, like all of Azul Systems’ JVMs typically are.
But before we got into discussing Azul Systems’ Falcon just-in-time compiler, I thought I’d do a bit of bear-baiting with Gil and tell him that I was sorry that in this new age of serverless computing and cloud and containers, and a world where nobody actually buys hardware anymore, that it must be difficult flogging a high-performance JVM when nobody’s going to need to download one and to install it locally. Well, anyways, Gil wasn’t having any of it.
Gil Tene: So, the way I look at it is actually we don’t really care because we have a bunch of people running Zing on Amazon, so where the hardware comes from and whether it’s a cloud environment or a public cloud or private cloud, a hybrid cloud, or a data center, whatever you want to call it, as long as people are running Java software, we’ve got places where we can sell our JVM. And that doesn’t seem to be happening less, it seems to be happening more.
Cameron McKenzie: Now, I was really just joking around with that first question, but that brought us into a discussion about using Java and Zing in the cloud. And actually, I’m interested in that. How are people using Java and JVMs they’ve purchased in the cloud? Is it mostly EC2 instances or is there some other unique way that people are using the cloud to leverage high-performance JVMs like Zing?
Gil Tene: It is running on EC2 instances. In practical terms, most of what is being run on Amazon today, it is run as virtual instances running on the public cloud. They end up looking like normal servers running Linux on an x86 somewhere, but they run on Amazon, and they do it very efficiently and very elastically, they are very operationally dynamic. And whether it’s Amazon or Azure or the Google Cloud, we’re seeing all of those happening.
But in many of those cases, that’s just a starting point where instead of getting server or running your own virtualized environment, you just do it on Amazon.
The next step is usually that you operationally adapt to using the model, so people no longer have to plan and know how much hardware they’re going to need in three months time, because they can turn it on anytime they want. So they can empower teams to turn on a hundred machines on the weekend because they think it’s needed, and if they were wrong they’ll turn them off. But that’s no longer some dramatic thing to do. Doing it in a company internal data center? It’s a very different thing from a planning perspective.
But from our point of view, that all looks the same, right? Zing and Zulu run just fine in those environments. And whether people consume them on Amazon or Azure or in their own servers, to us it all looks the same.
Cameron McKenzie: Now, cloud computing and virtualization is all really cool, but we’re here to talk about performance. So what do you see these days in terms of bare iron deployments or bare metal deployments or people actually deploying to bare metal and if so, when are they doing it?
Gil Tene: We do see bare metal deployments. You know, we have a very wide mix of customers, so we have everything from e-commerce and analytics and customers that run their own stuff, to banks obviously, that do a lot of stuff themselves. There is more and more of a move towards virtualization in some sort of cloud, whether it’s internal or external. So I’d say that a lot of what we see today is virtualized, but we do see a bunch of the bare metal in latency-sensitive environments or in dedicated super environments. So for example, a lot of people will run dedicated machines for databases or for low-latency trading or for messaging because they don’t want to take the hit for what the virtualized infrastructure might do to them if they don’t.
But having said that, we’re seeing some really good results from people on consistency and latency and everything else running just on the higher-end Amazon. So for example, Cassandra is one of the workloads that fits very well with Zing and we see a lot of turnkey deployments. If you want Cassandra, you turn Zing on and you’re happy, you don’t look back. In an Amazon, that type of cookie-cutter deployment works very well. We tend to see that the typical instances that people use for Cassandra in Amazon with or without us is they’ll move to the latest greatest things that Amazon offers. I think the i3 class of Amazon instances right now are the most popular for Cassandra.
Cameron McKenzie: Now, I believe that the reason we’re talking today is because there are some big news from Azul. So what is the big news?
Gil Tene: The big news for us was the latest release of Zing. We are introducing a brand-new JIT compiler to the JVM, and it is based on LLVM. The reason this is big news, we think, especially in the JVM community, is that the current JIT compiler that’s in use was first introduced 20 years ago. So it’s aging. And we’ve been working with it and within it for most of that time, so we know it very well. But a few years ago, we decided to make the long-term investment in building a brand-new JIT compiler in order to be able to go beyond what we could before. And we chose to use LLVM as the basis for that compiler.
Java had a very rapid acceleration of performance in the first few years, from the late ’90s to the early 2000s, but it’s been a very flat growth curve since then. Performance has improved year over year, but not by a lot, not by the way that we’d like it to. With LLVM, you have a very mature compiler. C and C++ compilers use it, Swift from Apple is based on its, Objective-C as well, the RAS language from Azul is based on it. And you’ll see a lot of exotic things done with it as well, like database query optimizations and all kinds of interesting analytics. It’s a general compiler and optimization framework that has been built for other people to build things with.
It was built over the last decade, so we were lucky enough that it was mature by the time we were making a choice in how to build a new compiler. It incorporates a tremendous amount of work in terms of optimizations that we probably would have never been able to invest in ourselves.
To give you a concrete example of this, the latest CPUs from Intel, the current ones that run, whether they’re bare metal or powered mostly on Amazon servers today, have some really cool new vector optimization capabilities. There’s new vector registers, new instructions and you could do some really nice things with them. But that’s only useful if you have some optimizer that’s able to make use of those instructions when they know it’s there.
With Falcon, our LLVM-based compiler, you take regular Java loops that would run normally on previous hardware, and when our JVM runs on a new hardware, it recognizes the capabilities and basically produces much better loops that use the vector instructions to run faster. And here, you’re talking about factors that could be, 50%, 100%, or sometimes 2 times or 3 times faster even, because those instructions are that much faster. The cool thing for us is not that we sat there and thought of how to use the latest Broadwell chip instructions, it’s that LLVM does that for us without us having to work hard.
Intel has put work into LLVM over the last two years to make sure that the backend optimizers know how to do the stuff. And we just need to bring the code to the right form and the rest is taken care of by other people’s work. So that’s a concrete example of extreme leverage. As the processor hits the market, we already have the optimizations for it. So it’s a great demonstration of how a runtime like a JVM could run the exact same code and when you put it on a new hardware, it’s not just the better clock speed and not just slightly faster, it can actually use the instructions to literally run the code better, and you don’t have to change anything to do it.
Cameron McKenzie: Now, whenever I talk about high-performance JVM computing, I always feel the need to talk about potential JVM pauses and garbage collection. Is there anything new in terms of JVM garbage collection algorithms with this latest release of Zing?
Gil Tene: Garbage collection is not big news at this point, mostly because we’ve already solved it. To us, garbage collection is simply a solved problem. And I do realize that that often sounds like what marketing people would say, but I’m the CTO, and I stand behind that statement.
With our C4 collector in Zing, we’re basically eliminating all the concerns that people have with garbage collections that are above, say, half a millisecond in size. That pretty much means everybody except low-latency traders simply don’t have to worry about it anymore.
When it comes to low-latency traders, we sometimes have to have some conversations about tuning. But with everybody else, they stop even thinking about the question. Now, that’s been the state of Zing for a while now, but the nice thing for us with Falcon and the LLVM compiler is we get to optimize better. So because we have a lot more freedom to build new optimizations and do them more rapidly, the velocity of the resulting optimizations is higher for us with LLVM.
We’re able to optimize around our garbage collection code better and get even faster code for the Java applications running it. But from a garbage collection perspective, it’s the same as it was in our previous release and the one before that because those were close to as perfect as we could get them.
Cameron McKenzie: Now, one of the complaints people that use JVMs often have is the startup time. So I was wondering if there’s anything that was new in terms of the technologies you put into your JVM to improve JVM startup? And for that matter, I was wondering what you’re thinking about Project Jigsaw and how the new modularity that’s coming in with Java 9 might impact the startup of Java applications.
Gil Tene: So those are two separate questions. And you probably saw in our material that we have a feature called ReadyNow! that deals with the startup issue for Java. It’s something we’ve had for a couple of years now. But, again, with the Falcon release, we’re able to do a much better job. Basically, we have a much better vertical rise right when the JVM starts to speed.
The ReadyNow! feature is focused on applications that basically want to reduce the number of operations that go slow before you get to go fast, whether it’s when you start up a new server in the cluster and you don’t want the first 10,000 database queries to go slow before they go fast, or whether it’s when you roll out new code in a continuous deployment environment where you update your servers 20 times a day so you rollout code continuously and, again, you don’t want the first 10,000 or 20,000 web request for every instance to go slow before they get to go fast. Or the extreme examples of trading where at market open conditions, you don’t want to be running your high volume and most volatile trades in interpreter Java speed before they become optimized.
In all of those cases, ReadyNow! is basically focused on having the JVM hyper-optimize the code right when it starts rather than profile and learn and only optimize after it runs. And we do it with a very simple to explain technique, it’s not that simple to implement, but it’s basically we save previous run profiles and we start a run assuming or learning from the previous run’s behavior rather than having to learn from scratch again for the first thousand operations. And that allows us to run basically fast code, either from the first transaction or the tenth transaction, but not from the ten-thousandth transaction. That’s a feature in Zing we’re very proud of.
To the other part of your question about startup behavior, I think that Java 9 is bringing in some interesting features that could over time affect startup behavior. It’s not just the Jigsaw parts, it’s certainly the idea that you could perform some sort of analysis on code-enclosed modules and try to optimize some of it for startup.
Cameron McKenzie: So, anyways, if you want to find out more about high-performance JVM computing, head over to Azul’s website. And if you want to hear more of Gil’s insights, follow him on Twitter, @giltene.
You can follow Cameron McKenzie on Twitter: @cameronmckenzie
We’ve been preparing for QCon New York for months, and finally it’s just around the corner! It’s one of the leading professional conferences for software architects, developers, and technical team leads to learn about the latest technologies.
There will be 3 packed days of sessions from industry leaders followed by 2 days of workshops. Selecting the best talks from the many that are being offered may be overwhelming, so if you’re looking for some help check out these seven talks that we’re especially excited to highlight.
Running applications in containers is an increasingly popular way of maintaining large, distributed stacks that change based on demand. The Java VM heritage makes it an ideal language for container-based infrastructures. With many moving parts and components, monitoring Java applications in containers requires planning and choosing the right tools to monitor the aspects that matter to you.
There are five components of a monitoring stack worth considering. I’ll briefly cover the first two and point you in the direction of useful resources that cover them, and then I will focus on the last three in detail.
Open source software has completely transformed the opportunities for software development. Now, Canonical is launching a new effort to bring these principles to programmable software defined radios and industrial equipment. Developers will be able to experiment with different wireless protocols for efficiency, security, or new architectures. It also threatens to disrupt the business model of wireless carrier providers. TheServerSide caught up with Maarten Ectors, VP of IoT for Canonical to find out what this revolution means for developers.
TSS:Noticing the way that startups like Uber, Netflix, and Airbnb, are disrupting legacy business models, it is fascinating to what the birth of a new dramatic shift like this might mean to traditional telco service and hardware business models. What makes it possible to build a better base station compared to legacy offerings?
Maarten Ectors: The magic lies in commoditization of software defined radios and IT infrastructure in general. Via the LimeSDR any type of wireless protocol can be used to receive and transmit data. The end result is that open source hardware based on standard Intel CPUs and programmable components like FPGAs becomes “good enough”. You no longer need specialized chips which are extremely expensive to develop. It is this “good enough” for service which is changing the economics.
The other element is “software defined” via app stores. If you can move away from a model whereby only one company can program a base station to a world where anybody can, then innovation is multiplied. Base station designers aren’t normally skilled in cloud, content distribution networks, games, and so on. By opening up the base station and simplifying how to deliver software for it, people with completely different skill-sets can help lower costs, reduce time to market and generate new revenues.
TSS: It looks like the initial crowdfunding is sort of experimental and relatively simple compared to larger wireless switches in terms of capacity and throughput. Is it the case that this is better suited for smaller scale deployments and experimentation, and that companies might innovate on top of this to build more cost-efficient carrier grade implementations?
Maarten Ectors: The LimeSDR was a crowdfunding campaign aimed towards developers. The LimeNet crowdfunding campaign is aimed towards anybody who wants to run or experiment with production-ready base stations. The target group is different. We first needed developers to make apps before we can launch a product with an app store. The LimeNet campaign is focused on carrier grade and creating a market for the developers that made apps in round one.
TSS: How might this kind of system make it easier to prototype out different wireless configurations?
Maarten Ectors: We have created two cloud backend stores for apps for base stations. The LimeSDR app store is an open store for developers to show whatever they have prototyped. Any new protocol, any new use case, new idea, new approach, can be easily shared with others even before it is a complete product. This allows Lime Micro to understand what is hot. Afterwards the best community initiatives will be offered to make a production ready version for the by invitation only app store: LimeNet. LimeNet is connected to the production-ready equipment and both best of community and commercial vendors can offer their solutions on it. The aim is to allow telecom operators to quickly launch new solutions and test them in field trials. If they work, they can be scaled out. If they don’t then they get removed. Both approaches will allow many different ideas to go very fast from idea to prototype to potentially production.
TSS: What do you see as some of the best tools and frameworks to simplify the development of this new style of wireless apps?
Maarten Ectors: Lime Microsystems is working with the open source community on packaging tools and frameworks that simplify the development of wireless apps. They have created their own tools to make apps with the LimeSuite and are working with PhotosWare, GNU Radio and many others. The tools we see today are just the beginning. We expect many more tools to emerge from the community.
TSS: What are some of the testing challenges in building these wireless apps and some of the best tools and practices to reduce defects and bugs?
Maarten Ectors: The app format, snaps (see snapcraft.io), allows for DevOps for Devices in which you can easily upload new code to the source repository, get it automatically tested via your CI and have a new version of the snap automatically uploaded to the store on what is called the “Edge Channel”. The channel approach allows developers to create nightly builds and have automated tools test their correct working from a unit test perspective. Afterwards a nightly build can be promoted to a beta channel and go through more thorough automated testing. Finally, it can pass via the release candidate to the stable channel. Telecom operators can have equipment in their R&D centers that pick up release candidates and test them automatically. If these versions work, they can get blessed and as soon as they become available on the stable channel, the production systems can automatically upgrade in a safe time window. If this upgrade goes wrong, then a rollback is always possible thanks to the transactional rollback capabilities of Ubuntu Core (ubuntu.com/core).
TSS: What kind of FCC and other regulatory concerns to buyers of these programmable devices need to address? In other words, how can you allow programmer flexibility while addressing concerns that developers/users will not accidentally or purposefully interfere with license holders?
Maarten Ectors: Lime Micro will be working on solutions for developers of protocols, holders of license spectrum and developers of apps that use both to be more easily managed. If an app uses a protocol for which you don’t have spectrum license, then in the future this SDR will not allow it. At the same time, we have partners looking into models whereby you can buy spectrum as a service. You just pay for the minutes and the type and location you need.
TSS: How do you expect open source SDR hardware and the ecosystem to evolve over the next 2-3 years, and what does this mean for developers?
Maarten Ectors: We are launching step 2 of a three-step process. Step 1 was about building an ecosystem of developers. Step 2 is about giving the developers a market to sell their apps. Step 3 will be about reducing the cost of an SDR to as close to zero as possible. This will be done by putting the SDR on a chip and even in the future include this inside other chips. With this approach, we will go from a $285-$500 SDR to a below $10 SDR which will open the possibilities to have an SDR in any wireless device, including smartphones. The future will likely be about each mobile app having the possibility to use their own protocol by negotiating this with the software defined radio in the base station. Imagine a world whereby Netflix and YouTube use a custom protocol. This world whereby wireless protocols are built to solve end-user’s and developer’s problems and are no longer a closed committee slow moving paywall exercise will be the real innovation SDR will bring. Wireless Innovation at Internet speeds, driven by GitHub and App Stores.
TSS: What is the state of adopting similar principles to bring innovation to other value chains like MRI-scanning, car engines, and industrial robotics?
Maarten Ectors: We are starting to App Store define IoT gateways, PLCs (called ALC or App Logic Controller, which controls anything from traffic lights, elevators, industrial machinery and robots, etc.), vending machines, other types of telecom and network equipment (e.g. Facebook Wedge Top of the Rack Switch), etc. At Mobile World Congress, we will show several other devices with app stores. If they are successful open source hardware will follow soon after.
A few weeks ago TheServerSide published a story about the discussion TSS editor Cameron McKenzie (@cameronmcnz) had with Eberhard Wolff (@ewolff) about not only his latest book, but also the various trends and technologies that he sees shaking up the world of DevOps, continuous delivery and enterprise software development. The podcast of the interview is presented here again, along with a full transcription of the interview. Enjoy.
An interview with Eberhard Wolff
Cameron McKenzie: Eberhard Wolff is one of the experts that the server side follows on Twitter. A software engineer with going on 20 years’ worth of experience, you may have read one of his books on Spring or continuous delivery or micro-services, or you may have seen him speaking on one of those topics at a conference in North America or Europe. We noticed that he’s got a new book out, “A Practical Guide to Continuous Delivery,” so we scheduled an interview, and the first question was, “What is the current state of continuous integration and continuous delivery?”
Eberhard Wolff: I’d say that continuous integration is, nowadays, a commodity up to the point where people actually forgot what it actually means. They start to use continuous integration just to do regular compiles while in fact, they’re doing feature branches, postponing the integration. Oftentimes, people are actually doing feature branches, and that means a team might be doing something for quite a long time and not integrating. They sort of miss the original point about continuous integration. So I think that’s the status that we are in, that people actually forgot about the original ideas behind continuous delivery and are now rediscovering them.
Cameron McKenzie: So when you encounter clients using this feature branch approach, what do you tell them and how do you go about correcting them?
Eberhard Wolff: The first thing I tell them is that if you don’t have a problem, don’t fix it. Feature branches are actually a fine way of doing it. If they do have problems integrating back into the main branch, then I would set up some additional measures like doing regular integrations or maybe even changing it altogether so that you just have the master branch and you do all work on trunk.
Continuous delivery changes the whole thing a little bit because usually, it means that the master branch is special because it’s the one that goes into production. Even if you do feature branches and you branch them off, they are different from the master branch because they are usually not going into production. And that means that I would argue, through continuous delivery, probably it’s not the best idea to combine the feature branches.
Cameron McKenzie: Now, are there any software tools that you recommend for organizations that are going to take a continuous delivery type of approach to DevOps, or are you one of those advocates that falls into that camp that says tooling is one of the last things you talk about when you go down this path?
Eberhard Wolff: Concourse CI is an interesting tool because it does everything on Docker. Actually, a colleague of mine is quite an advocate of that, so I found that interesting. Generally speaking, I would argue, in particular, if you talk about continuous delivery and if you look at the book, it’s actually all about testing.
So in the book, I talk about unit tests and acceptance tests and performance testing and all these kinds of things. And usually, if I go to a customer and I need to consult them concerning continuous delivery and also probably micro-services, the first thing that I talk to them about is, “What is it really that keeps you from doing much more frequent releases?” Usually there is some manual sign off or some manual acceptance testing, and I think that is something that’s often forgotten. So, you know, just having a Jenkins and doing deployment automation, I think that’s not the key challenge. The key challenge is to go into production without manual sign-off.
Cameron McKenzie: Now, we’re all familiar with unit test and testing our business logic and, even to a certain extent, integration testing, but what about testing the UI? I mean, how can we do changes to a user interface to the way that a person interacts with their tool and actually test that and validating that? Aren’t there some serious challenges in terms of automating UI testing?
Eberhard Wolff: I would tend to agree that if you talk about UI testing concerning, you know, look and feel and these kinds of things, that’s hard to automate and probably even impossible. Having said that, what I usually see in customers is that they rely on UI. They are doing UI testing, but I think what they are really doing is acceptance testing. So, you know, it’s not about “does the UI work propertly” and it’s also not about “that the UI looks nice.” If they do automated UI testing, it’s usually about does the system do what it’s supposed to do, which, in my opinion, is acceptance testing.
The road that usually leads there is that that’s what testers do, right? They start the application, they take a look at the UI, they do stuff in the UI, they validate that the results are correct, and they automate that. So you have a UI test, which is, in fact, really an acceptance test. And I think that’s bad because that way, you get fragile tests because if you do a minor tweak to the UI, it breaks your test even though the business logic might still be the same. And also, those tests tend to be slow and even sometimes unreliable.
So if you ask me about the main challenge concerning UI tests, I would argue that the main challenge is that they become acceptance tests, and you should look at different ways of doing testing in that regard and, you know, you should do proper acceptance testing using other tools. And that is why I really wanted to include that chapter about behavior driven design because I think it’s key to understand how to do proper automated acceptance testing and how to try to avoid manual sign-offs from the customer.
Cameron McKenzie: Now, you clearly have an issue with manual sign-offs, but what about exploratory testing? I believe you talked about it in your book. What’s the role of exploratory testing and the manual aspect of exploratory testing?
Eberhard Wolff: I think it’s fine to do manual testing. I mean, that’s basically what exploratory testing is about, you know, to have a manual look at specific parts of the application that’s causing problems or something like that. So I would argue it is a tool where you can have a specific focus on specific areas of the application that are somehow the problem, you know, from a performance perspective, from a business logic perspective, etc.
It’s something that is going on, you know, to fix problems in specific areas, but it should not be a block on the continuous delivery pipeline, which would clearly be if it required a sign-off.
Cameron McKenzie: Now, there’s no denying the containerization trend that I’m seeing more and more clients being pressured into using Docker and integrating Docker and containers into their architecture. How has containerization and tools like Docker change the way that continuous integration and continuous delivery is done?
Eberhard Wolff: Yeah, I think you are pointing at a very important point. Docker allows different ways of doing integration and continuous integration and so on. And I would agree that there would probably be a new generation of tools. I believe Concourse is one of the tools that’s already mentioned. So I think that is an interesting point, you know, to really rethink continuous integration, to make the continuous integration server aware of Docker containers, to make the continuous integration server itself run in Docker containers and also to obviously create Docker containers. I believe that, how shall I put it, Jenkins is not the greatest tool anyway, right? So I think, for that reason, the additional pressure that you mentioned from the move towards Docker, I sort of welcome it because I’m looking forward to a new generation of CI tools.
Cameron McKenzie: So what are the things that you would like to see in the next generation of continuous integration and continuous delivery tools?
Eberhard Wolff: A more rigid isolation of the different builds of the different projects. If you look at Jenkins, I would argue that it’s been built with the idea of setting up your continuous integration platform, your continuous integration pipeline in the tool itself and in the web UI. Of course, that has changed now because there are now job description languages. But I would argue that ideally, a modern continuous integration tool should be code-based anyway. So, you know, that there’s a job description for the continuous integration pipeline from the very beginning and it should be built with that in mind. So I think those are the points.
What I do like about Jenkins, of course, is the huge ecosystem and all the plug-ins that you have, which, again, are sort of an issue because it means that no Jenkins server looks like the other one and it’s hard to get all those plug-ins to work together. So that’s another shortcoming, probably, but, you know, it’s trade-off because if it wasn’t for those plug-ins then Jenkins would be much less valuable.
Cameron McKenzie: So I’m assuming that you believe that adopting a DevOps culture is important to making continuous integration and continuous delivery work.
Eberhard Wolff: Oh, yeah, absolutely. So I believe DevOps is all about development and operations working together, which is to say that it’s not about an organizational change, so I think it’s not so important to have dev and ops report into the same managers. What I do think is important is that both share in the responsibility for the application and that there is no finger pointing but true collaboration. So I think that’s the key point. And of course, if you do change the organization, then that might be beneficial for such collaboration.
I think continuous delivery is one way or one thing that you can achieve more easily if you do DevOps. That is to say if I look at the continuous delivery pipeline at one point, it’s about deploying stuff into production, which is usually an operation’s thing. And on the other hand, if the start of the pipeline, just doing the compilation and building the software, unit testing that’s on, that’s more a dev thing. So if you have the whole pipeline, you can only build it if you have a DevOps organization. So let’s say that continuous delivery is one thing that you can enable by having a DevOps organization. That’s sort of how it fits together in my opinion.
Cameron McKenzie: Now, one of the reasons we got together today was so we could talk about your latest book, “A Practical Guide to Continuous Delivery.” What is it that you wanted to achieve by writing this book and what is the takeaway that readers will have once they finished reading it?
Eberhard Wolff: What I want to achieve with my book, and that is actually something that also sets it apart from the original “Continuous Delivery” book, is that it is the practical introduction. So I actually talk about specific tools. I give advice about how to use them. I have some examples how to use the tools. People can learn from that and build their own experiments. So that’s basically how it works in my opinion.
Cameron McKenzie: Now, if that conversation doesn’t convince you that Eberhard Wolff knows what he’s talking about, I don’t know what will. I strongly suggest that you, like the server side, follow him in Twitter. That’s @ewolff. That’s with two Fs. And more importantly, go pick up his book, “A Practical Guide to Continuous Delivery.” I know you’ll enjoy it.
Agile gets all the press, but Waterfall has proven to be a fairly trustworthy approach to software development for a very long time. It’s definitely not going anywhere. In fact, it’s still the preferred methodology for many of the world’s largest enterprises for some very good reasons, so don’t ever think that the Agile versus Waterfall debate has been concluded.
At a recent Agile vs. Waterfall Debate, which pitted the two methodologies against each other, four experienced technology professionals dug deep into both approaches. The conclusion at the end of the night was unanimous: It’s imperative to choose a process that works for the organization and for the situation at hand. And sometimes, that’s still Waterfall. Here are five ways to tell if that’s the case in an upcoming project.
#1 The project has to be right the first time
With all its flaws, Waterfall is still the most time-tested method for software development. It is designed to provide maximum control and reduce uncertainty. For situations with clear requirements, regulatory compliance factors, and a strong possibility that failure will mean lots of very bad press, most enterprises will opt for Waterfall in the Agile versus Waterfall debate, just to stay on the safe side. Mark Yarbro, performance test manager at a major financial institution, put it plainly. “When we screw up, it is front page news. It’s got to be right the first time.” Agile may get things done fast, but there’s still a risk of missing the mark. “You’ve got to be doing the right thing, not just doing the wrong things faster.” Cyclic waterfall is often used where speed and control need to be balanced.
#2 Timing and coordination are essential
Mark deals with the issue of synchronizing multiple teams on a daily basis. “We have twelve hundred applications. We release many of them on a ninety day cycle. The way it works is we get everyone together so they are working in lock step. It’s very difficult to release one product when it doesn’t line up with the others. We are doing performance testing on thirty different apps to get them all ready at the same time.” It’s not just the apps, but the platforms and the entire ecosystem that must be upgraded simultaneously. That’s not something that Agile is good at doing, and one reason why Agile is so difficult to scale. “Agile is a great way to get things done if you don’t know what you need, if the customer is not being clear. But it’s much more difficult to get everyone lined up and releasing at the same time.”
#3 Fulfilling the scope is the point of the project
Obviously, it’s ideal to have a workable piece of software at the end of the day, but both Agile and Waterfall have been known to fail in that regard. Waterfall tends to place more emphasis on the process of doing the work according to the plan. Sometimes, that’s just about making the project as profitable as possible for those providing the software development or related services. Enterprise Agile Coach Jay Packlick pulled no punches in shining a light on why Waterfall is a tempting choice when pockets are deep. “If you’re a government contractor getting paid by the number of hours, the answer might be I’m going to optimize for stuff. What is your customer optimized on? IS my problem getting solved? To be clear, Agile tends to be biased on delivering what you need. It’s generally value focused. Waterfall is biased toward delivering lot of billable stuff.”
Satyapal Chhabra, Founder and Managing Principal at Ideliver, agreed to an extent, but pointed out that well-defined scope can be a good thing. “Waterfall is about the scope. Not because you don’t want to deliver the value, but because the scope is driven by someone who is qualified, who knows what is needed.” Knowledge and expertise are highly valued in Waterfall when it comes to creating the overall plan and setting the course of action. In contrast, “Agile tends to think, ‘We can do it because we have inclusion by the right people.’ That’s where Agile becomes cyclic and goes on forever. Waterfall tends to at least deliver something that you can hand out at the end.”
Of course the notorious Motorola phone and the original Obamacare marketplace website were both brought up in the debate as examples of technically delivering the scope but not a usable end result. But in a reasonably well run Waterfall project, the scope would encompass the value and help the project from getting pulled off course to pursue other objectives.
#4 High level stakeholders don’t like risk
For organizations that are used to Waterfall, making the transition to Agile may prove a bridge too far to cross, making the whole Agile versus Waterfall debate moot. Mark admitted that Agile is a superior methodology in many ways, but it relies heavily on the human factor. “Agile is ugly and messy. Real Scrum is so much fun. It’s a battle royale, muddy and messy, and you get so much accomplished. But it’s not pretty. Management, especially in big organizations, is very intolerant of messy, seemingly out of control processes. The whole organization has to change. People have to think and act differently all the way up the chain, and it’s hard to change human behavior.” In that case, getting Agile off the ground might actually take longer and deliver poorer results than sticking with traditional methods.
#5 The culture doesn’t mesh with Agile
Speaking of people, when teams are made up of less skilled or less self-directed people, or when feedback and collaboration are not highly valued, Waterfall may be the only functional option. Jay cautioned against trying to go Agile in the wrong circumstances. “If I’m working in an organization where I give the boss bad news and get fired, if everyone shuts up when the boss walks into the room, if I’m in a place where people don’t give a crap, they just want to get in, get a paycheck and get out, they don’t want to have a conversation or do Kumbaya, they’re probably not going to succeed with that framework. You have to fit your framework to your problem, cultural or otherwise. Don’t try to shove Cinderella’s slipper on her big fat sister, because it ain’t gonna fit.” To mix one final metaphor, when the Waterfall fits, go with the flow.
According to a 2013 survey by Ambysoft, projects following the Agile method have about a 64% success rate. That’s higher than the dismal numbers for Waterfall (at less than 50%), but it still means there are an awful lot of projects that should be agile that end up being simply fragile. What happens to make Agile fail? Here are seven of the obstacles that tend to block success, with advice from four experienced professionals in the enterprise software development field.
#1 Waterfall by any other name…
Performance Test Manager Mark Yarbro described what he thinks most software dev teams are doing when they claim to be doing Agile. “In Scrum, you have a bunch of people sitting around in a meeting, picking things off the backlog, starting to give estimates, and the developer’s just making stuff up, and the QA guys are just copying what the developers are saying. After a day or so of that, it’s all story pointed out, so then they all start hammering out code. QA’s sitting there, writing some test cases, but really waiting for the code to be delivered. So a week or two into the sprint, code starts being given to the QA folks, they’re starting to test things, Development is sitting around waiting. They’re planning the next sprint, pulling more things off the back log and figuring out what they’re going to be working on next. You know what that is? That’s Waterfall. You’re doing four week waterfalls. That’s RAD (Rapid Application Development). That’s what most people are doing when they call it Agile.”
#2 Feedback doesn’t happen when it should
In the perfect world, the end user or true customer would be sitting in from the very first meeting. Sadly, that’s rarely the case. That means there are always assumptions being made. Satyapal Chhabra, Founder and Managing Principal at Ideliver, highlighted this problem. “If you have continuous sprints, when does the real end customer start participating? Probably sprint eighteen or nineteen. That participation is the fundamental premise of Agile. But it doesn’t happen.” Mark agreed, “They should be there from the start.” In his experience, teams end up using proxies to stand in for the customer, with predictable failures in their ability to correctly predict what the customer really wants.
Enterprise Agile Coach Jay Packlick pointed out that, if there is a known lack of information, Agile must adapt to take the missing knowledge into account. Obviously, the later the customer becomes involved, the longer it will take to identify and satisfy their requirements. This is a common cause of cost and budget overruns in Agile. “Here’s where things go wrong. They have a situation where the customer isn’t going to be available until sprint nineteen, but they don’t solve the problem of ‘What am I going to do to get feedback?’ That’s a failure in one of the core principles of Agile which is to change your approach so that you solve your problem. You inspect and adapt. You have to change the system, or they will go on for months and fail. I don’t care what process you’re doing. If it’s not working and you don’t change it, it’s going to fail.”
#3 Agile documentation is almost always atrocious
According to Mark, who worked in Agile shops for many years, it’s easy to get carried away with the rush and bustle of Scrum and not pay attention to sustainability. “In daily standups there aren’t supposed to be any status updates. No ‘I’ve been working on…’ only what you’ve accomplished, what you hope to accomplish, and any impediments to getting that done. Accomplishing things constantly is the fuel that keeps Agile working. Otherwise, it’s a grind. But it’s also used as an excuse not to do any documentation. Enterprise needs to think bigger. The actual development is the tip of the iceberg. The maintenance is what’s under the water.” He described organizational amnesia that results when developers move on and there is no one left who remembers the details of the code. Greater accountability is a must. “Pure Play Agile doesn’t take into account that what gets done isn’t what’s expected, it’s what’s inspected.”
#4 Agile testing often stinks as well
Not only is there a serious shortfall in documentation, but testing throughout the project often suffers from lack of attention. Mark commented again, “Agile needs to have better testing. To make things work, you need QA people who are developers and developers who aren’t afraid of testing.” Quality Management specialist Brian Bernknopf agreed. “You can’t have an Agile SDLC with only Agile development where you’ve got devs working on stories and QA working on releases. Other traditional QA responsibilities may change, but you still need governance. In daily builds, what type of testing is going to happen at check-in? How do you know if those are the rights tests?”
Unfortunately, many teams haven’t figured out how to make things work when they go Agile and QA often gets sidelined. That means they need to regain a seat at the table, even if it’s in a different chair. “It’s a changing role. They need to be able to sit inside a Scrum and jump in and solve a problem. In a similar way, Developers need to be able to help write a test script. In an agile project, QA is a role and not necessarily a person. You could have a developer with a QA mindset in that position.”
#5 Key stakeholders become less involved over time
Agile is not a free for all. It requires discipline. Shreyas Batt, Cofounder and CEO of FusePLM, found that out the hard way. His team’s recent project thankfully did not fail, but it certainly took longer than planned because they weren’t consistent about following the rules. In this particular case, working with an offshore development team added logistical and time zone issues to the mix. “We had weekly meetings. But over time, the project manager or Scrum manager was sometimes not available. Then it was just a bunch of devs but no one to guide them and keep them on track on their side. On our side, we weren’t privy to the internal planning. You need the right people on the call.”
#6 Demos become optional instead of mandatory
Failing to prioritize the Agile structure and ensure constant feedback and communication proved to be an error for Batt’s team as well. “We took their word for what was going on. It didn’t give us a good picture. We didn’t want to micromanage, but to have insight into progress. At the start, we would have a demo each week. Later, we didn’t enforce that well enough. They told us what they were doing but didn’t actually deliver the code for testing until eight weeks later. That’s when we realized they didn’t understand the requirements. Agile enforced correctly would have really helped.”
#7 The desire to go Agile is fuzzy
Jay revealed that the first issue he seeks to help resolve with organizations is figuring out what they actually need to change. Most of the time, the people he speaks with aren’t actually certain. “That’s the first problem. They want to do something but aren’t clear about what outcome they really want.” Then comes the challenge of figuring out if changing to an Agile methodology can actually happen. “You have to determine who is the locus of control or the champion. Sometimes, nobody within the organization is a champion, it’s unclear, or the person isn’t acting to lead that change.” The right conditions for change must be met and the right people must have an appropriate level of involvement. Otherwise, trying to do an Agile project in a traditionally Waterfall culture simply won’t work—and the project is ruined before it even begins.
We recently published an interview in which Ken Owens, Cisco Systems’ chief technology officer of Cloud Platforms, provided a very concise and definition of cloud-native computing that pulled together the concepts of DevOps, containers, microservices and modern software development. We recently had the audio for that podcast transcribed, as we thought it was worthwhile having it reproduced in text for those who aren’t particularly in love with audio files. The following is the audio podcast, with the transcription of Owen’s definition of cloud-native computing below.
Cameron McKenzie: If you’ve been following TheServerSide’s Twitter feed lately you’d know that we’ve been doing a boatload of articles lately on cloud-native computing. Now in our Quixotic quest to nail down a good definition of exactly what cloud-native means, we’ve been given the names of a number of experts in the field, one of whom is Cisco’s Kenneth Owens.
Now it’s actually been incredibly difficult trying to nail down a precise definition of what cloud-native computing means. To the purest, it’s simply the deployment of a micro-service into a managed and orchestrated container. To others, you’re not doing cloud-native if you’re not Agile and doing DevOps. There really is no expert consensus on the term. Now having said that, Ken Owens gave us the best definition of cloud-native computing that we have heard to date. In his definition he pulls together the idea of cloud-native, he pulls together the idea of microservices, he pulls together Docker, and he then discusses how all of that rounds back upon itself to incorporate things like automation and DevOps. It’s like he’s provided a unified theory of cloud-native computing. And what’s even more amazing, he does it in less than four minutes. So here’s Ken’s response when we asked him to define the term cloud native, I think you’ll find it’s the best definition of cloud-native computing that’s around.
Ken Owens: I kind of have two ways to answer that question. Sorry for that, but as you know, I’m on the TOC (Technical Oversight Committee) for the CNCF (Cloud Native Computing Foundation) and the way that we as a community have defined cloud-native is container-packaged, dynamically orchestrated (and I always add ‘managed’, so it’s kind of managed-systems-architecture type of approach, which is where Kubernetes comes in), and microservices-architected. And that microservices-architected part is where all the magic happens, if you will.
So I like to then sort of further define microservices-architected. I think that gets to the roots of your question as to why there are two different opinions about how cloud-native is defined.
So when you think about microservices-architected, there’s a wide range of, I guess you could say opinions, about what that means. But I believe the patterns or the common sort of view that most everyone in the space has is that it is about completely automating your software, a focus on a small set of interfaces that you define as services, like a containerized service if you will, and then looking at how to consume and expose services out of your interfaces.
And so it’s really a mind-shift in how software development occurs because now the application developer kind of owns all of it. In some cases you can say that they’re still relying on the infrastructure team to provide them some infrastructure, but for the most part, they kind of own the life-cycle of the development, the deployment, and the ongoing integration and deployment aspects of that service for the rest of the life of that service. Some people call it DevOps, some people call it, you know, 12-Factor application architecture, but in effect, the developer kind of owns the life-cycle, end to end, of the services they create, whereas in the past there was an infrastructure team that they would pass some things to and there was the operations team that they would pass some aspects to. Now, all of those three teams are sort of being merged together into a cloud-native team.
Cameron McKenzie: So there you go, a concise definition of cloud-native computing that pulls together containers, microservices, the cloud, automation, and DevOps. It’s a pretty impressive feat.
More articles from Cameron McKenzie:
- Why the Amazon S3 outage was a Fukushima moment for cloud computing
- Software ethics and why ‘Uber developer’ stains a professional resume
- It was more than user input error that caused the Amazon S3 outage
- Don’t let fear-mongering drive your adoption of Docker and microservices?
- Stop adding web UI frameworks like JSR-371 to the Java EE spec
Google’s annual worldwide developer conference (Google I/O) kicked off at the Shoreline Auditorium in Mountain View, California on Wednesday morning. Seven thousand people are attending live, and others are viewing the event online at 400 Google I/O Extended events in 85 countries.
This year’s mantra is “AI first,” integrating machine learning with each of Google’s software and hardware products. The keynote was a rapid-fire delivery of announcements:
- A new initiative named Google Lens integrates visual recognition with user help. Point your phone’s camera to a label containing a network password. Google Assistant enters the password automatically and connects you to the network. Point the camera to a phone number and Google Assistant dials that number. Point to a concert advertisement. Google Assistant plays a sample of the band’s music and offers to book concert tickets.
- Developing artificially intelligent apps requires two phases — a training phase and an inference phase. In the training phase, the software learns about the problem domain. In the inference phase, the software applies the learning to new situations.
The training phase is computationally intensive. To address this issue, Google announced its new Cloud TPU, which is available on the Google Compute Engine immediately. The Cloud TPU hardware is optimized for both training and inference, and can deliver a whopping 180 teraflops of computing power. Developers can visit http://g.co/tpusignup to sign up.
- Google announced its new Google.ai initiative to coordinate AI efforts and teams. The initiative has three parts: research, tools, and applied AI. The research part includes AutoML, in which neural nets design other neural nets. This task is computationally challenging, and Cloud TPU is making it possible.
- Starting immediately, Google Assistant will accept commands that are typed or tapped as well as spoken. Typing is advantageous because, in public venues, people may not want to speak commands. Typing, tapping and speaking to Google Assistant are all integrated, so an interaction with the Assistant may use all three interaction modes.
- Google Assistant is now available on the iPhone!
- Google Assistant is now available in French, German and several other languages. Google Home will launch in Canada, Australia, France, Germany and Japan.
- Effective immediately, Actions on Google handles purchase transactions. With voice interaction and fingerprint scan, you can use Google Pay. You don’t have to enter an address or credit card number.
- A new feature in Google Home is called Proactive Assistance. Here’s how it works: Google Home knows about an upcoming event on your calendar, knows where the event takes place, and calculates the travel time to the event given the current traffic conditions. When you say “What’s up?” to Google Home, the device reminds you that it’s time to leave for the upcoming event.
- In the next few months, Google Home will make no-cost, hands-free calls to any landline within the United States or Canada. Google Home recognizes up to six different voices in a household. So if you say “Call Mom,” the device determines which member of the household is making the request, and calls that person’s mother.
- Spotify will offer free music service to Google Home.
- Google Home will have Bluetooth support, so you’ll be able to play music from any Bluetooth enabled device on the Google Home speaker.
- In addition to its voice responses, Google Home will display information on your phone’s screen and, through Chromecast, on your TV.
- Google Photos will have three new features. With Suggested Sharing, Photos identified the people in your images and offers to share the images with those people. With Shared Libraries, Photos automatically shares images with certain characteristics to people you select. With Photo Books, you can purchase a hard copy of your best images based on criteria that you specify.
- In the next few weeks, YouTube will provide 360 degree video on your Android TV. You’ll issue voice commands to request a certain video. You’ll use your remote to move from side to side within the video scene. Live 360 content will be available.
- Earlier this year, YouTube launched Super Chat where users pay to pin comments on live streams. Users can now trigger physical actions using Super Chat. During the keynote, users paid to drench two fellows known as the Slow Mo Guys with 500 water balloons. All proceeds went to charitable causes.
- TensorFlow is Google’s machine intelligence software library. With the newly created TensorFlow Lite version of that library, developers can add deep learning capabilities to apps that run on small, mobile devices. Smartphones will become even smarter.
- Samsung’s Galaxy S8 and S8+ will add virtual reality features using Google Daydream.
- HTC and Lenovo will use Google Daydream in their standalone VR headsets. All the processing power will be in the headsets. You’ll experience virtual reality without having to attach a cable or a smartphone.
- The new Android Go initiative optimizes the Android system to run on entry level phones. In this context, an entry level phone is one with between half-a-gigabyte and one gigabyte of memory. As one part of this initiative, a Data Saver feature economizes on the use of network resources by compressing the data that’s being sent. Another part named YouTube Go Offline Sharing saves videos for viewing when the network isn’t available.
- With Google Expeditions, students experience things that they can’t ordinarily experience in the safety and comfort of their own classrooms. Students move around a room while they look at a tablet device’s screen. The tablet show anything from the terrain in a far away land to a view from inside the human body.
Later this year, the Expeditions platform will add augmented reality to its repertoire. The tablet’s display will be able to superimpose virtual images onto real objects in the room.
- A new Android App Directory helps user discover new apps. Users can try an app before buying the app.
- Google’s Instant Apps API is now available to all Android developers.
- Many Firebase SDKs will soon be made open-source.
- The new Play Console Dashboards summarize app diagnostics to help developers analyze and improve their apps. In addition, a developer can add Firebase Performance Monitoring to an app with only one line of code. In addition,
- For enhanced security, Firebase will include phone number authentication.
Beta availability of Android O
I write books about Android development, so for me, the most interesting announcement was the availability of a beta for the next Android version – codenamed Android O. In this version of Android, developers will be able to write code in the Kotlin programming language. This is a big deal for developers because it’s a departure from Android’s long-standing Java-only tradition.
Kotlin is completely interoperable with Java, so existing Java code will work without modification. New apps can be built using Java, using Kotlin, or using any combination of the two languages. JetBrains (the company that created Kotlin) will work alongside Google to help the language evolve as a language for mobile platform development. Best of all, Kotlin is available immediately in the new Android Studio 3.0.