We have gone from the city that never sleeps to a world that is continuous. That’s right, it seems along with the world shrinking, it is always on, someone is always watching or doing. Continuous has become the new black.
Nowhere is this more true than in IT. We have Continuous Delivery, Continuous Integration, Continuous Testing, Continuous Monitoring, continuous this, continuous that, continuous everywhere. Infosec is not immune to this either. We are trying to protect against continuous attacks by deploying continuous scanning, continuous threat protection, continuous monitoring, all of it part of our continuous security. All of this sounds like an old George Carlin routine. But it’s not it, it is the way things are today.
Of course all of this continuous around security had to lead to continuous compliance. After all who would want to be compliant at only a point in time (even if that point was at the time of audit)?
The newest version of the PCI DSS tries to move compliance from point in time compliance to continuous compliance. Some question whether this puts too big a burden on merchants. How many resources can they dedicate to compliance to make sure it is continuous? Others say that continuous is the only way that makes sense.
For me there is a lesson here that security can learn from DevOps. The key is automation. Automation is the secret weapon in doing continuous. Without automation, continuous would require too many resources to truly succeed. But with automation we can duplicate, perform act over and over again without a human initiating every step, every move.
That is not to say that humans are no longer needed. On the contrary, automation frees up humans to work on tasks of a higher nature. Automation frees up humans from the repetitive, mundane tasks that need to be done over and over again. Working instead on things that are of a higher value (at least they should be).
But wait there’s more! Not only does automation empower continuous, automation brings speed. Once we automate, we can speed things up as well. So not only are we performing continuously, we are also performing faster.
Now we are automating tasks without human intervention and at the same time doing them faster. I know for many a security admin the hairs on the back of your neck are standing up. This can’t end well. Things are going out of control. Automating and speeding things up almost goes against being cautious and careful.
But as counter-intuitive as it may be, automating and performing faster can actually result in being more secure and more compliant. Wait lets repeat that again: by automating and speeding up performance we can actually become more secure and more compliant.
How? You don’t believe me? Impossible you think? How can continuous make us more secure and more compliant? Is it even possible to do all of this continuously?
This is the topic that I along with Jody Brazil, CEO of Firemon are going to explore as hosts of a P2P session at RSA Conference. The session is on Thursday at 10:20am, it is titled Continuous Network Compliance: Finding Flaws and Betting Futures, you can click on the link for more info. Put it on your RSA calendar if you are attending. The P2P sessions only hold 25 or 30 people so come early.
I will post a follow up to this post after the session with some of the discussion points around this. If you would like to hear the answers before then though, you will have to come to the session. See you in San Francisco at RSA Conference.
The line up for DevOps Connect: SecDevOps @ RSAC is complete. What a great job Gene Kim and Josh Corman did lining up a power-packed schedule. Here is what the day is shaping up to be include:
8:50 to 9:00am Alan Shimel and Mark Miller – Opening remarks and welcome
9:00 to 9:50am Gene Kim/Josh Corman – Rugged DevOps: Going Even Faster With Software Supply Chains
9:50 to 10:30am David Mortman – DevOps Myths Versus Real World Realities
10:30 to 10:45am Bio and email break
10:45 to 11:20am Julie Tsai – Windfall Wins: DevOps Empowers Agile Security and Compliance
11:20 to 11:55am Jez Humble – Continuous Delivery
noon to 1:30pm lunch break
AFTERNOON SESSIONS (ROOM 1)
1:30 to 2:00pm Constantine Cois – DevOpsSecFail: DevOps Security Anti Patterns
2:10 to 2:40pm Terri Potts – Leading a Horse to Water and Enticing Him to Drink
2:50 to 3:20pm Nick Galbreath – BYOD: Bring Your Own Dependencies
3:30 to 4:00pm Jessica Devita – No White Boards Allowed
4:10 to 4:50pm Rich Mogull – Building Your SecDevOps Toolkit
AFTERNOON SESSIONS (ROOM 2)
1:30 to 2:00pm Dan Cornell and Chris Curlyo – Blending the Automated and the Manual: Making Application Vulnerability Management Your Ally
2:10 to 2:40pm Damon Edwards and Alex Honor – Coaches and Toolsmiths
2:50 to 3:20pm Dan Cundiff – Why DevOps != the Wild West and How Embracing it Can Improve Security
3:30 to 4:00pm Chris Corriere – Automating Enterprise Security
4:10 to 4:50pm Chris Walsh – I’m the New Security lead, and I’m Here to Help
Pre-registration for the event is already sold out, but seating is on a first come, first serve basis and open to all RSA badge holders. So Monday of RSA Conference week, April 20th, Moscone Center West, room 2018. Come be part of a great day of DevOps and Security!
Containers are all the rage these days. You’re just not cool if you’re not using Docker or some other container technology to build and deploy your IT infrastructure. Traditional containers, however, lack sufficient security for some industries and companies, so Microsoft developed Hyper-V Containers.
Container platforms like Docker and Rocket have significant momentum and have quickly become established as a de facto way of developing and deploying applications. Microsoft already entered into an arrangement to bring native Docker container support to Windows Server, but now it is going a step farther by creating Hyper-V Containers that combine the agility of containers with the security of virtualization.
Hyper-V Containers ensure that code running in one container object remains completely isolated. The Hyper-V Container object cannot impact other container objects or the host operating system, or vice versa, because it is a separate virtualized container. Mike Neil, general manager of Windows Server for Microsoft, explained in a blog post, “Leveraging our deep virtualization experience, Microsoft will now offer containers with a new level of isolation previously reserved only for fully dedicated physical or virtual machines, while maintaining an agile and efficient experience with full Docker cross-platform integration.”
IT admins will appreciate the fact that Hyper-V Containers can be created and deployed using the same development and management tools used for traditional Windows Server Containers and that they integrate with Docker for cross-platform deployment. Neil points out that applications developed as Windows Server Containers can easily be deployed as Hyper-V Containers without any modification—enabling organizations to take existing containerized apps and re-deploy them in a more secure manner.
It seems like security is always an afterthought to any new technology concept, and containers is no exception. It started out as a good idea that caught fire, but it wasn’t until it hit critical mass and achieved mainstream adoption that security became a factor. As larger companies, or organizations in highly-regulated industries look at jumping on the container bandwagon, though, security becomes a mandatory component.
Virtualization has been used in hosted environments for years as a means of isolating different systems running on the same physical hardware or network. Microsoft’s Hyper-V Containers take those same principles and apply them at the container app level so that security-conscious organizations can have some peace of mind and remain compliant with security mandates as they embrace containerization.
Microsoft’s strategy of integrating Windows Server Containers and native Docker support in Windows Server and Azure was a big step in the right direction. Adding the security of Hyper-V Containers is brilliant. Microsoft is doing an excellent job of pivoting its business model and not just embracing cloud and DevOps technologies, but raising the bar and taking the lead.
As a side note Microsoft also announced Nano Server—a new minimal footprint implementation of Windows Server optimized for cloud hosting and container technologies. The Nano Server installation includes the bare minimum components necessary. Microsoft claims the result is smaller server images, faster deployment times, decreased network bandwidth consumption, and reduced administrative overhead. In other words a Nano Server installation of Windows Server will just do what it’s supposed to do with minimal interaction or oversight so IT personnel can focus on more important things like the Hyper-V Container apps running on it.
Myself and the gang have been talking about Cloud a lot recently as we are embarking on a multi-year journey. Cloud is fashionable but is this another cool toy for the techies? As an architect I think the most powerful question in my toolbox is “why”.
Why are we doing this?
Does it add business value?
What are we trying to achieve?
As IT folk it’s instinctive to go straight into the “how” but its the “why” that is the really important question. Get that right and how to do it should be relatively easy. A solution is much easier to put in place if you’ve really captured and understood what it is you are trying to accomplish. I think there are 8 reasons why companies commonly move the Cloud – I’m specifically thinking about IaaS and PaaS here but I guess this also could apply to SaaS in parts.
Scale
The massive amounts of processing power or data storage that public Cloud offerings can achieve would be difficult to achieve building your own solutions (certainly at any kind of realistic price point).
Elasticity
The ability to expand and contract resources (such as compute) depending on your requirements. Traditional IT departments buy capacity in advance which is unused until it is required. The elasticity of Cloud allows us to buy what we want, when we need it and not be constrained by fixed overheads.
Cost saving/model
Some companies believe that moving to the Cloud will save them money.
I think the ROI for Cloud is really difficult to ascertain though. How do you compare apples for apples when Cloud is a different model to on-premise?
It might be easy to say a server costs X to run each year (power, data centre costs, depreciation, support etc) and compare that to a Cloud server. However, what is the cost of having to wait for 3 weeks to get a new server on-premise when you can get it in 5 minutes in the Cloud?
It’s not an easy calculation to be made and I don’t think I’ve seen a really convincing argument from either side.
One insurance company I know said they did some calculations and Cloud was 3x more expensive than on-premise. I’ve seen Cloud companies boast that IaaS is 3x cheaper than on-premise. You should do some due diligence on the cost of Cloud of course. However, in my eyes it’s too complicated and fuzzy to create a compelling story at the moment. Does this mean you shouldn’t move to the Cloud? Absolutely not – but focus on the other benefits too as cost alone is too difficult to accurately determine. The move from CapEx to OpEx is also a difficult question for many and really needs to be thought about. How do you accurately budget for a service if you are using the elasticity and scale features of the Cloud for example?
Future proofing
The rate of new features hitting Cloud providers is pretty astounding. AWS for example have over 450 services now and more hit the shelves every month. You probably won’t need the majority of these features now but what about in the future? As an IT department we can’t predict the future but we can help to respond to it. Why build it yourself when you can buy it as a commodity?
Time to market
With Cloud being pre-packaged and largely automated the time to market for adopting resources is often significantly lower than doing it yourself. You might have a really neat automated server build at your company but chances are you still need to wait for the storage guy or the network guy to do something. Often its not even the time waiting for something to be spun up – its the time waiting for a person to become available in order to press the button to spin it up. For example, in my company it takes 2 hours to build a VM. However I might not be able to book a resource to kick the process off for 2-3 weeks depending on their availability. I don’t think this is a problem that only public Cloud can remedy but again why build it internally?
Resilience
This is a bit contentious but bear with me. Cloud outages happen. On-premise outages happen. However, I would argue that due to the scale of some of things like Azure (and the ease of employing it) that cloud is more resilient than traditionally hosted IT. But…. Only if your application is written/configured in such a way to take advantage of the multiple availability zones and the resilient functionality that Cloud providers…..errrm….provide. If you simply lift and shift from on-premise to Cloud you are just moving the problem. If you treat Cloud just like another data centre you’ll get just another data centre with much the same problems as you currently have. Perhaps even worse. At least in your data centre if there is a problem you are in charge of your infrastructure guys and can prioritise (shout at) them. What is going to happen when you are speck on the Azure infrastructure? Is your voice going to get heard? Is it heck.
Increasing competitive advantage
Although there is value getting your IT teams to run infrastructure (it’s likely your business couldn’t operate without it), does they offer competitive advantage? What competitive advantage do you realistically gain over your rivals by running your own SAN, servers etc? Wouldn’t it be better if your teams were concentrating on high-value tasks that separate you from competitors rather than undifferentiated heavy lifting? Competitive advantage can be realised through such things as…
Lowering costs
Improving quality
Increasing the pace of change
Improving end user support
Innovation
Spending more time understanding the business
Wouldn’t you want your teams spending time on the above rather than worrying about provisioning blades and making sure backup tapes get revolved?
Geographic reach
As companies grow and their worldwide reach increases (customers and internally) then it means getting data closer to the end user.
Your Google ranking is probably going to suffer in the US if you are serving your website from the UK.
Your Citrix session is likely to be “sub-optimal” if you are sat in London trying to access your VDI farm in Australia.
How do you organise downtime for maintenance when your worldwide presence is open 24×7 because of your global reach?
The global reach of public Cloud companies enables to provision resources nearer the people that need them.
A word of warning
In order to fully realise the benefits of the Cloud (such as scale, resilience) applications need to be architected accordingly. You are unlikely to realise the benefits I’ve talked about simply through “lift and shift”. It’s also worth mentioning that people, process, technology, culture all need to be addressed as part of the a Cloud adoption. This isn’t just a technical exercise and nor is Cloud a panacea for all of the challenges that face IT.
DevOps practices originated at startups, where nimble Development and Operations teams pioneered the concept of cross-functional collaboration to speed up software release cycles. By 2009, DevOps became a recognized industry practice: a software development methodology that promised higher velocity for enterprises working to get products to market more quickly. Many enterprises have since embraced DevOps among their software development teams, and early adopters are now taking it beyond code to other parts of their organization.
Unfortunately, successful cross-organization collaboration is uncommon outside of Dev and Ops teams. With the Internet of Things bringing software and hardware together in previously disconnected devices and industries, collaboration among design, development and product management teams has become crucial. There are technical, procedural and cultural challenges which must be addressed to bring the same level of DevOps success to other areas of an organization.
The State of Collaboration
An important place to start is understanding the interactions between different groups in an organization.
Consider one of the most frustrating areas of the software release process prior to DevOps-style collaboration. Builds would be “tossed over the wall” from Development to Quality Assurance, and then from Quality Assurance to Operations, with each team moving on to other things as soon as a build was handed over. Visibility into the overall status of the project was non-existent.
When other departments collaborate, what is the level of visibility into the work being produced by the groups that depend on one another? Does marketing know if the latest feature made it past the initial legal review and the likelihood of it being included in the final product? The answer is usually no; there is little visibility into the process and decisions are shared close to project deadlines. Applying DevOps practices to an organization’s entire product pipeline changes the collaboration paradigm, expediting time to market and improving overall quality.
Culture, Automation, Measurement and Sharing (CAMS)
CAMS is relevant when both technical and non-technical teams collaborate. As seemingly unrelated teams are required to work together, it’s important that they have a culture of shared accountability.
Skipping the details of specific tools and technologies, one key consideration for organizations to recognize is that automation is crucial to a repeatable process, enabling speed and scale. It also provides a high level of visibility, as it’s closely coupled with the sharing of data. When only one team is manually updating metrics, communicating what’s going on is manageable. But what happens when other groups are dependent on work being produced by a group that’s updating its data manually? What if multiple groups depend on knowing the status of a task in a timely manner? Manual processes result in an endless flood of phone calls, emails or instant messages asking if information is up to date.
The measurement aspect of DevOps opens up a can of worms. It’s important not only to determine what should be measured but also to have a common way of discussing how it’s being measured. Establishing a common vocabulary across an organization for day-to-day tasks can be extremely difficult.
In these situations, it is important to go back to the core benefits of trying to bring the DevOps style of collaboration to other groups in an organization.
What is the desired business outcome?
Why don’t current processes meet requirements?
How could change positively benefit employees’ daily work?
As people become comfortable with “why,” discussions of “how” become easier.
Once changes are underway, it’s important to make sure that there is a single place where people can obtain accurate status updates and share information. Bringing DevOps into the enterprise takes time, but providing visibility into any project in an automated, transparent manner will show the positive impact of sharing information in a timely way.
Most importantly, try to quickly demonstrate success—however small. There will be roadblocks, political objections (an unfortunate reality) and people who just don’t want to change. But by measuring and demonstrating success and tying it back to business outcomes, you will set up your organization for success.
Like many other initiatives, the key to a successful DevOps program is intention. To drive this home, an old joke: how many therapists does it take to change a lightbulb? Just one. But it has to really want to change.
About the Author/Jonathan Thorpe
Jonathan Thorpe, Technical Marketing Manager, Perforce Software –Before joining Perforce as a Technical Marketing Manager focused on Continuous Delivery and DevOps, Jonathan Thorpe held technical marketing roles at CFEngine, Serena, and Electric Cloud, where he specialized in DevOps culture and automation technologies. In his spare time you can find him reading, playing with all of the current video game consoles, dabbling with mobile software development, and playing with the Raspberry Pi.
Change is difficult. It can be painful, disruptive, and costly. Making a case for change requires us to win over hearts and minds. In my experience, we need to win the hearts of the ‘do-ers’, the people whose daily work is going to be disrupted. And the minds of the executives, whose financial support and personal sponsorship we need to make change happen.
A Lean boxscore allows you to address both the hearts, and the minds. Boxscore is a simple tool which we use to compare the current state with the future state, and turn that comparison into a compelling case for change.
Step One: Current State Baseline
Let’s start with where we are today, by capturing performance metrics that tell an accurate story of today’s development lifecycle. This may mean looking beyond the project plan to the reality, by the way. By interviewing or workshopping with development and operations teams, we get a true picture of the way the development process currently performs.
We’re always interested in end-to-end leadtime, of course – from the moment the business provides a prioritized set of requirements, to the moment that functionality is in production and working as intended. We’re also interested in how much wait time there is within the process – how much time between steps, waiting for an approval, a developer, or a tester. We do this by creating a value stream map, capturing all those metrics and validated by the teams who work within this process every day.
We want to look beyond leadtime and wait time too. We capture the number of resources involved in each release, the number of handoffs, and the number of bugs caught at each stage of development and deployment. If we can get to it, we might capture the percentage of time a developer spends writing code for their current release, as opposed to firefighting issues from the last release, arguing over schedules, trying to secure an appropriate environment, or other ‘non value adding’ activities. We might also capture some usage statistics, or other measure of customer satisfaction, and any relevant performance indicators, like server response time.
Before moving on, it’s crucial to ask stakeholders: ‘is this a fair reflection of the way things currently work?’
Step Two: Future State Target
This next step requires some imagination, and some bold thinking. Imagine a world where you’ve adopted DevOps: you’ve removed the waste within the development lifecycle and instilled the ‘shift left’ principle in all your working practices, your ‘4 in a box’ teams are rapidly developing, testing and deploying code, Cloud-based environments give you immediate provisioning, and automation and smart tooling have taken the bellyache out of testing. What does that future look like? How quickly can you develop – if provisioning is immediate? How many bugs do you expect to put live – if testing is automated and your production environment matches your test environment? How many changes to scope – if you’re working with smaller batches and faster delivery?
We create a new value stream map, which details the way this brave new process will work in practice. This allows us to set sensible but challenging targets for our future state.
Before moving on, be sure to ask stakeholders: ‘are these targets achievable, if we make the changes we have outlined?
Step Three: So What?
Finally, we get to the money question. What’s it all worth? For each improvement there will be an impact. Many of these will be financial. Ask your stakeholder ‘if we can get this new functionality out to market 2 months faster, what does that mean for revenue?’ Or ‘if we reduce the number of defects in production by 90%, can we reduce our operating costs?
Putting a dollar value on the financial impact will win over those minds with a logical, fact-based argument. Now, investing in a DevOps pilot seems like something they can’t afford NOT to do.
And the case for change for hardworking developers, testers and production resources? Metrics like number of handoffs, bugs and rework, and batch sizes can easily be translated into ‘how much pain you have to live with each day at work’ to win those hearts over.
As a Lean Coach working in IT I often hear development teams refer proudly to their scrumboards as an example of Kanban. To which I say, ‘that’s a great start… but it’s really only just the start’.
Let’s start with what a scrumboard is, and does. A scrumboard is a visual display of work, showing the progression of user stories in development. As you see some stories moving through the phases of development, and others getting stuck, you huddle to figure out how to get them unstuck. Now you’re using your visual display for visual management, which is a great Lean solution.
Change management boards, like the one used in The Pheonix Project, are another good example of visual management. The physical display of changes, shown by release date and system, is a great way to get a handle on the amount of change and risk you’re throwing into live production. When you start moving them around to limit the risk, again, you’re using visual management.
The word ‘kanban’ roughly translates as ‘signboard’, and a scrumboard really is a good start. But it’s only half the story. Until you limit the number of stickies on your change management plan, or the number of story cards on your scrumboard, you’re really only half way to kanban nirvana.
True kanban requires you to limit the amount of work in progress and to establish the pull of work. In a manufacturing plant, a kanban card is attached to each unit in production. When a completed unit is, say, taken off the shelf by a customer, the card is sent back into the production line to signal that there is now an empty slot on that shelf which needs replenishing. Limiting the kanban cards sets a constraint around the amount of work in progress – and this limit should reflect the capacity of the process. In the same way, you can limit the number of story cards, boxes on your scrumboard or spaces in your change management plan. When a scrumteam complete a story that frees up a slot for them to pull the next story into their workload: the visual display should reflect this by showing each team’s capacity. In addition to visual management, you can create rules around work in progress, requiring each scrumteam to limit their intake so they have no more than, say, two workpackages in progress at a time.
This is all well and good, but what do you do when demand from the business requires a greater capacity? Historically you’d have thrown that extra demand into the mix, asking your teams to do more with the the same amount of resource, maybe pushing back a release date to accommodate the extra work.
Kanban requires you to create additional capacity in the system to allow for the additional demand either by:
rebalancing the load, for example switching some resources from a work package that is ahead of schedule
removing or deprioritizing other work and putting work on hold
increasing resources by bringing in new team members
All of these actions will generate some churn, so it’s going to be worth a tough conversation with your customer first. ‘Are you sure you want me to disrupt the current sprint, or the next release, to squeeze this in? How about we pick it up next week, when we’ll have some new capacity?’ By limiting your work in progress, you’ll be speeding up the flow of development into production, so you can make that ‘next week’ promise with increasing confidence.
So the next time you walk over to that scrumboard, why not take the next step, and limit the work in progress to truly establish kanban.
“DevOps” is the latest rage. Leading edge companies like Netflix, Etsy, and Intuit (the “Unicorns”) have transformed their I.T. Development and Operations organizations into a new culture known as DevOps: Development and Operations working collaboratively together to accelerate the pace of software and application delivery. But they didn’t implement DevOps. A DevOps transformation to their culture was the outcome of their implementation of continuous delivery of software. Continuous delivery is a process that applies automation and orchestration technologies to the application lifecycle. In this webinar you will learn how your organization can implement continuous delivery as a step toward your own DevOps transformation. With continuous delivery, you can accelerate application delivery which will allow I.T. to better meet the needs of the organization. With continuous delivery, I.T. becomes a business enabler.
Alan Shimel, Editor-in-Chief of devopsy.kinsta.cloud. An often-cited personality in the security and technology community and a sought-after speaker at industry and government events. Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.
Panelists:
As CloudBees’ Sr. Director of Product Marketing, Dan Juengst leads the product marketing efforts for the CloudBees Continuous Delivery Platform powered by Jenkins. Dan brings 20+ years of high tech experience to CloudBees with expertise in grid computing, high performance computing, and application performance. Dan has worked as both customer and vendor at both startups and enterprises. Dan’s resume includes Red Hat, Sun Microsystems, SGI, Wily Technology, Terracotta, and Lockheed Martin where he started his career computing hypersonic reacting airflows around Mach 30 flight vehicles.
Some of you may be aware that we have published a full blown media kit including an editorial calendar for the rest of 2015. For the month of April our focus is Rugged DevOps. It started yesterday with a great post by David Geer, Rugged DevOps: From Idea to Automation to Impact. It will continue all month with stories around infosecurity and DevOps. At the end of the month we will pull these all together into a Rugged DevOps special edition available to all of our newsletter subscribers.
But that is not all we are doing with Rugged DevOps. We are also publishing an Ebook that will be available RSA Conference week, April 19th. The EBook written by our own Ericka Chickowski will take a deep dive on the intersection of security and DevOps. We will also be printing 1000 copies of the book which will be distributed at our various activities at RSA Conference. In case you are not already aware, here is what we have planned for RSA Conference week:
DevOps Connect: SecDevOps Edition– Monday, April 20th – 9am to 5pm, Moscone Center – Featuring keynotes by Gene Kim, Josh Corman, Jez Humble and over a dozen other top names in DevOps and Security, this events pre-registration is already filled up. However, seating is on a first come, first serve basis and open to all RSA badge holders. So come early or try later in the day if there are any open seats. If you are interested in DevOps and infosec, this promises to be a don’t miss event.
DevOps Wine-ing Event – The after party for the DevOps Connect conference, the DevOps Wine-ng event is a tradition started by Josh Corman and the Sonatype team. This year’s event is sponsored by Sonatype, Puppet Labs and devopsy.kinsta.cloud. In order to gain admission to the event you need an invite or pre-registration from one of the sponsors. devopsy.kinsta.cloud will be offering invites in the next week. Most of the speakers as well as DevOps community and InfoSec community members will mingle in a relaxed atmosphere.
In addition to these DevOps related events, I of course will be helping to produce (along with a great team of Jennifer Leggio, Mike Rothman and Rich Mogull) the 9th annual Security Bloggers Meet up and Blogger Awards. This event is open only to those who write or podcast about infosecurity. It is usually a highlight of RSA Conference week. If you do write about security and have not been invited, write me at editor@devops.com with where you write and we can try to get you an invite.
Beyond that I along with my good friend Jody Brazil, CEO of Firemon will be hosting a peer-to-peer session on Thursday at 10:20am, Continuous Network Compliance: Finding Flaws and Betting Futures. It should be a good discussion looking at the idea of Continuous Security. P2P sessions only sit 25 to 35 people so come early to make sure you have a seat for that one.
On top of all of this I will be live blogging RSA Conference here on devopsy.kinsta.cloud, so stay tuned for that.
BTW, last month’s topic was “Containerization”. We are in the process of gathering up all of the great articles we had around this topic last month. We will package this content into a PDF document that again will be available to our newsletter subscribers. You can subscribe to our newsletter in the right hand sidebar of this page.
The tally of smartphone usage worldwide is mind-numbing: Even as far back as 2012, more people on earth had access to a mobile phone than had access to a toothbrush. Even more mind-numbing must be the stats on the untold millions of those mobile device users in various states of rage at any moment while waiting for their content to finish downloading. Mary Meeker’s 2014 “State of the Web” report states 30% of all mobile phones are smartphones. The usage of the smartphones is growing in a compounded manner.
I’m confident that my own frustration resonates with those millions of users. And it’s only getting worse. I think about the plight of the next N billion mobile users who will depend on constantly overburdened mobile networks in all parts of the world.
I was fortunate in being able to turn that frustration into a mission, when I founded PacketZoom. I had developed the blueprint of an idea for a remedy while working at Google, and then spent two years to productize and trial the technology in the heavy R&D phase of PacketZoom starting in 2013. But we weren’t content to tweak the existing protocols to save a few milliseconds here and there – and neither were countless app developers around the world, who faced the same conundrum. Why not? Stats have proven that mobile downloads taking more than six seconds cause about half the users to defect from the app they are using – unaware that the network, and not the app, is to blame. And it’s well past time for incremental approaches to fixing the problem. [citation: https://blog.kissmetrics.com/loading-time/]
The turning point for me was my first-hand experience on a trip to India while trying to load the first screen of an application while on a moving subway. Only an exercise in extreme restraint prevented me from bludgeoning my phone – which, of course, was not the culprit. Clearly, the problem was unsolvable using the prevailing technology that had been jury-rigged over 40 years to serve every new use-case that came along. Maybe that time-honored, but worn-out technology had to be replaced!
The last few years we have seen an explosion of apps on mobile phones. The next few years promise to bring an order of magnitude larger number of devices in response to the “Internet of Things” phenomenon. If we continue using the same old protocols, the interminable waits for mobile content will become intolerable.
Time to Lose Four Decades of Losses
So what exactly is the problem with the legacy protocols? After all, they’ve been made to work for today’s use cases. Well, allow me to explain.
Let’s start with IP (Internet Protocol). IP addresses were intended to be solidly and reliably attached to a computer forever, in the same way a street address is solidly and reliably attached to each house. (And note that a smart phone is just another computer.) A packet sent to that address could go to only one place (the one house – or, in our analogy, the one computer). But now, in the year 2015, the IP address is but an ephemeral property of a mobile device. It’s as if everyone lives in a van now and your address depends on where you parked your van at the end of any day.
Today, the IP address of your mobile device might change while you walk from your office to the parking lot. As you move from your office WiFi to the LTE connection outside your office, and as you move through myriad disconnections and reconnections while travelling in personal or public transportation, you can be “taking” and “releasing” dozens of IP addresses during the course of your commute.
The upshot is, that when an app on your mobile device starts communicating with the cloud, every change of IP address causes the app to initiate the communication from the beginning – a so-called “cold start”), rather than from the point where the previous communication paused at the point of disconnection. That’s one very big problem, resulting in time lost through duplication of transmissions.
What’s more, each new reconnection to the network requires establishing a new TCP session, a session that utilizes the 40-year-old technology, TCP (or Transport Communications Protocol). But guess what? Each new TCP session starts cold and, according to the TCP algorithm, has to gently ramp up to full speed every single time. And the lost time due to those delays adds to the lost time created by continuous disconnections and reconnections that occur in all mobile environments.
TCP has been honed over the years to work “tolerably well” for general use over all possible kinds of networks. It was originally designed to connect huge computers, administered by professional sysadmins, and housed in meticulously maintained facilities with triple redundant power. It does the job that its least-common-denominator design is expected to do – that is, to get a stream of data from one computer to another (i.e., from one IP address to another) reliably.
Those are the guarantees of the TCP protocol. What it doesn’t guarantee however, and doesn’t even address, is speed. It uses the most conservative method possible to get your data packets from one place to another. As a result, user-level protocols (e.g., HTTP) get cluttered with hacks atop other hacks to try to work around TCP’s lack of concern for speed.
Consign TCP and HTTP to Their Rightful Place
Now imagine this conversation from sometime in the early 2000’s among boffin from companies making web browsers:
Boffin A: “TCP doesn’t allow us to use the full available bandwidth of the available channel (DSL, dial-up, or those new-fangled cable modems.”
Boffin B: “No problem! How about we open six TCP connections at the same time. Let them fight it out among each other.”
Boffin A: “Done.”
Boffin B: “We’re geniuses!”
Well, in fact, web browsers have been built around this approach ever since that ill-fated day. But the web runs on Hypertext Transport Protocol, aka HTTP, version 1.1 for the last decade and a half! HTTP, as an application-level protocol, knows nothing about speed either. And so browser vendors, over the years, have come up with a mish-mash of folklore-based tips, tricks and hacks to somehow keep this train running.
Fast-forward a bit, and a lot of these tips and hacks have been refined and codified into the latest revision of HTTP, version 2. The old protocol, the hacks to keep it alive, and now the new version of the protocol, are focused on making the web faster. The problem? Accessing the web accounts for only 14% of the uses of smartphones.
And therein lies the disconnect. For almost two decades the web was the dominant application platform. Gigantic hardware and software platforms (and companies) have been built to service the web. (Note how the biggest cloud platform in the world is called “Amazon Web Services”). TCP/HTTP sufficed for web access, but the constraints of what can be done in a web browser have held us back from evolving to the protocols designed for the predominant application of the Internet today: native mobile apps.
Quite simply, for any application running in a web browser, there’s nothing that you, the app developer, can do to fix the underlying network transport. But a new dawn is upon us. The dominant platform for applications is not the web anymore. It’s the native apps on mobile devices. And just like that, we’re free of the shackles of HTTP and even TCP. We, as app developers and our supporters, are free to invent protocols that make sense for this spottily connected, packet-lossy, high-latency mobile world. Evolution, by nature, works at a glacial pace. It’s now time for invention — and maybe even a few quantum leaps. Packetzoom has taken the first step towards fixing these problems by designing a more modern protocol purely for mobile use case. Learn more about it at https://packetzoom.com/learn.html. Here is a short video showing the PacketZoom difference:
About the Author/Chetan Ahuja
Chetan Ahuja is the Founder/CEO/CTO of mobile networking startup Packetzoom Inc. Prior to starting Packetzoom in 2013, Chetan worked on software and networking performance in companies such as Google, Admob and Riverbed where he gained a deep appreciation of the key role of network speed on application performance and thus on user happiness. He holds a Masters degree in computer science from Michigan State University and a Masters degree in computational chemistry from Indian Institute of Technology, Mumbai. He likes to spend the entirety of his free time watching old episodes of Monty Python and Start Trek (TNG) with his family or playing ping-pong with co-workers.
As 
