Thanks for participating and celebrating our birthday with us!
Claim your t-shirt by filling out the form below.
Please note only those who tweeted during the devopsy.kinsta.cloud birthday contest are eligible.
Author: Alan Shimel
-
PacketZoom Announces Mobile Speed as a Service, Enabling Mobile Apps to Access Cloud Content Up to 10X Faster
First Round Capital, Baseline, Founders Collective and Tandem Capital Back Innovation Designed to Address Mobile Users’ ‘Need for Speed’
San Mateo, CA – April 6, 2015 – PacketZoom, pioneering Mobile Speed as a Service (MSaaS), today announced a completely re-envisioned platform that addresses mobile app users ‘need for speed.’ The service, designed specifically for mobile app developers and today supporting millions of users, speeds up app content download time from the cloud by up to 10 times. The PacketZoom service retires the 40-year-old TCP protocol, leveraging a new protocol that identifies the device as the address for data packets and easily accommodates for the intermittent nature of mobile connections in an intelligent, fault-tolerant way. PacketZoom is designed to work particularly well in low-bandwidth networks or areas with spotty coverage. To leverage the PacketZoom service, mobile app developers simply drag and drop the PacketZoom Speed SDK into their app, which immediately provides unprecedented speeds for downloading cloud content.
Defying conventional technologies that at best deliver marginal performance improvements, PacketZoom comes to market with prominent investors such as First Round Capital, Baseline, Founders Collective and Tandem Capital, who provided the seed funding for PacketZoom and its proprietary protocol-based service.
With this announcement, PacketZoom addresses the stark reality of mobile-user behavior: more than two-thirds – 68 percent – abandon an app due to slow loading, according to Zogby Research, a custom research firm. Digi-Capital Mobile Internet Investment Review 2015 Executive Summary provides further evidence of fickle and impatient mobile user behavior.
“There are many mobile apps offering slow, clunky hotel booking services . We stay ahead by ensuring our iPhone app is very accurate and very quick – essential when people are booking time-sensitive last minute hotel deals,” said Harry Jones, co-founder & CPO, Top10, a site that specializes in finding top hotels based on destinations. “Once we integrated PacketZoom into Top10, we significantly sped up data downloads for our one million users and increased click-through rates – helping convert more visitors to customers.”
Innovating for Speed
The underlying PacketZoom protocol eliminates legacy network techniques that have been critical to mobile-network operation but delay content delivery including DNS lookups, three-way TCP handshakes, slow starts, and aggressive back-off to reduce packet loss. By eliminating the most challenging obstacles of legacy technology, PacketZoom enables delivery of mobile app content up to 10 times faster than otherwise possible.
PacketZoom also handles connections differently than legacy protocols, which consider the device’s IP address as the destination for data packets. By identifying the device itself, and not its IP address, PacketZoom easily accommodates for the intermittent nature of mobile connections in an intelligent, fault-tolerant manner, ensuring continuous connectivity as any mobile device moves across networks. And because the PacketZoom protocol incorporates sophisticated “situational awareness,” it always knows a device’s location, tracks dead zones, and recognizes packet drops and other critical factors in real time. All these capabilities are provided through the PacketZoom stack without any client or service side code changes.
“We tried several solutions in the past but we were either unimpressed or unsuccessful. We have 69M installs of four games worldwide and about 2 million monthly active users. As the demand for HD quality graphics grows in the mobile space, so do the sizes of our games and subsequently the need for us to stream content from the cloud. Streaming takes time and adds friction to the first load experience,” said Victor Rubba, CEO of Fluik Entertainment, a creator of games for mobile devices. “PacketZoom helps remove the friction and avoids compromising the quality of our games. Initial download times are now faster and the visual experience and quality of the graphics in our games improved as well. We see less players leaving before ever really experiencing the game. Sitting and waiting for content to finish loading now takes seconds and in this day and age, seconds is about as much patience as players can muster.”
Easy-Install SDK Makes Mobile Speed as a Service a Snap for Apps
App developers can quickly integrate PacketZoom’s Mobile Speed as a Service via an industry-first drag-and-drop SDK, eliminating the need involved changes to the app. PacketZoom developed the SDK in response to challenges of native mobile app development.
“With more than $32 billion in investment planned for mobile-first and mobile-only startups in 2015, there is no doubt there is an exciting opportunity to solve the mobile performance problem,” said Bill Trenchard, First Round Capital. “PacketZoom has resisted the temptation of force-fitting legacy technologies by tweaking parameters to solve problems for which they weren’t designed. They have been tenacious about finding a solution that works for modern app developers. It’s easy to call a new approach a ‘radical departure’ from the norm, but that’s exactly what PacketZoom has done. They have literally rethought and reengineered mobile content delivery down to the underpinnings.”
“Every mobile app developer knows that the fate of their app is based on the user experience which drives loyalty to their app,” said Chetan Ahuja, CEO of PacketZoom. “Unfortunately, too many apps miss their chance at mass adoption because slow data downloads kill the user experience. Our early traction with app developers like The ArtStack, Fluik Entertainment, Frenzoo, Proletariat, Top 10 and Voltage shows that this is a real problem for developers of all sizes, all around the world. As more companies move to take down websites and move their users to mobile apps, performance is more important than ever.”
For more information, please visit: www.packetzoom.com
About PacketZoom
PacketZoom is changing the equation for mobile productivity, delivering the only Mobile Speed as a Service (MSaaS) platform that allows developers to speed downloads of mobile content from the cloud by up to ten times. Built on a patent-pending protocol that makes existing protocols obsolete, the service enables developers to drag and drop the PacketZoom Speed SDK to their applications, reducing go-to-market times and eliminating the technical challenges that have hampered competing approaches to fostering productivity with mobile apps. The company’s MSaaS platform has been adopted by companies such as ArtStack, Fluik Entertainment, Frenzoo, Top10, and Voltage Entertainment USA. PacketZoom is backed by investors including First Round Capital, Baseline, Founders Collective and Tandem Capital. More information is available at www.packetzoom.com.
###
Editorial Contact
Suzie Linville
Trainer Communications
415.800.5371
-
Chef defines the DevOps workflow with Chef Delivery
At ChefCon today Chef made a major announcement unveiling Chef Delivery a “new DevOps workflow product that for the first time enables the continuous delivery of infrastructure, runtime environments – including containers – and applications.” Chef has examined the use success patterns of many of its thousands of customers to distill what they believe is the formula for success in a DevOps environment.
I had a chance to speak with Alex Ethier, VP of Product and Jay Wampold, VP of Marketing at Chef about Delivery. They were both really jazzed as they think this is a real game changer for not only Chef but the entire DevOps market. Chef is already a leader in the DevOps community with a rapidly growing base of customers in the Global 2000 and a dominant adoption position among AWS customers. Delivery will extend the Chef platform into the entirety of the DevOps workflow.Chef believes this is the time to expand the Chef platform to the entire DevOps workflow. Just about every analyst firm and survey data indicates that DevOps is on the way to wide spread adoption among IT teams of all sizes. While DevOps is about cultural change, once the organization recognizes the advantages to a DevOps culture, tools that leverage this culture are sure to expand their footprint.
I asked Alex and Jay if Delivery would bring Chef into competition with other DevOps tool vendors. For instance Jenkins and CloudBees in the CD and CI area would seem to be square in the cross hairs of Delivery. While on its surface this would seem to be the case, Delivery is actually a platform that is designed to leverage APIs and open source to to work with a large ecosystem of 3rd parties including Jenkins, CloudBees and other players in the DevOps ecosystem. I am still not 100% sure where the cooperation will end and the competition will begin, but I guess we will have to wait and see how that shakes out.
Based on Chef’s customer experience research they think this is what the flow of DevOps looks like:
DevOps lifecycle step by step Some steps are and will remain manual. Chef is seeking to play in the automated areas. Yes this is an ambitious move by Chef. If they succeed they will leverage their already dominant position in the DevOps configuration management field into becoming a dominant player in the entire DevOps life cycle.
Powering this life cycle is the fact that with the move to the cloud today’s enterprises are moving from static systems to rapidly changing services. This is putting new pressures on IT departments to perform in a “high velocity IT” manner. The key to all of this is of course automation. Under it all Delivery seeks to automate CI, CD and continuous testing.
Chef’s CTO, Adam Jacob had this to say about Chef Delivery, ““The tools we use reinforce the behavior; the behavior reinforces the tool. Thus, if you want to change your behavior, change your tools.”
Other highlights of Chef Delivery from the Chef press release are:
- Robust Pipeline: Chef Delivery provides a shared pipeline and proven workflow for software development that safely takes code from a developer’s or operations engineer’s workstation through build, test, and production.
- Platform for Collaboration: Each step of the Delivery pipeline incorporates automated testing to provide developers, operations engineers, compliance and security officers, and IT architects rapid feedback on proposed changes. The common workflow allows personnel of each IT discipline to work together with full visibility into the flow of changes through the pipeline. Policies can be easily applied at each step to ensure maximum change control and governance.
- Sophisticated Analytics: Chef Delivery provides metrics for all stages of your development pipeline. With full audit capabilities, you can track both pipeline performance and activity, manage permissions and access comprehensive change history from easy to use dashboards.
- Scalable Architecture: Chef Delivery was designed from the ground up for performance and scalability. Its architecture is fully integrated with the Chef Server and designed to meet the demands of the largest and most complex enterprise IT environments.
- Full Ecosystem Integration: Chef Delivery integrates with an extensive array of operating systems and runtime environments, including public cloud platforms such as Amazon Web Services and Microsoft Azure, as well as runtime environments such as Docker containers.
- Availability: Chef Delivery is currently available through an invitation program
- Pricing: Chef Delivery will be sold in 2015 on a subscription basis.
This could indeed be a real game changer for already high flying Chef. While at ChefCon today I intend to ask many of the partners and vendors exhibiting here how they view Delivery and what kind of integrations we can expect to see from them for it.
One thing for sure is the DevOps tools market is evolving and maturing rapidly. Tool vendors will have to move quickly to allow high performing IT teams to move at the speed of DevOps.
-
Variable Speed DevOps: A Deep Dive
About 2 months ago I wrote an article on “Variable Speed DevOps“. To be clear I first heard the term used by Carmen DeArdo, Director of Application Development at Nationwide. It was a response or play on the 2 Speed IT dilemma. In 2 Speed IT, emerging digital processes coexist with traditional ones. The implication is that the “traditional” processes can’t run at the speed of the emerging digital ones (even older digital can’t run at the speed of newer digital processes). But the question is do they have to?
According to Carmen and other folks I have spoken to, the key is not making processes run faster than they are intended to. It is blending all of the different processes and the speeds they run at to mesh together into one finely tuned machine. Like the different size gears within a Swiss watch, perfectly tuned to keep the correct time down to the millisecond. Variable Speed DevOps is about the fine tuning of an organizations IT machine to make all of the different size and speed gears work flawlessly.
Of course this could be much easier said than done. Carmen has spoken about Nationwide’s journey in this regard. I have also had the pleasure of participating in a Google Hangout with Carmen, Sanjeev Sharma and Rosalind Radcliffe of IBM where we discussed this concept as well.
The notion of Variable Speed DevOps existing in Enterprises with traditional Systems of record, co-existing side by side with new Systems of engagement and code is destined to be as dominant in the world of DevOps within enterprises as Hybrid Cloud is going to be the dominant form of Cloud.
I believe that the idea of Variable Speed DevOps deserves a deeper look. There is much that we can learn and share by delving deeper into the concept and hearing from experts who are on the front lines of Variable Speed DevOps. To do this we are teaming up with our friends at IBM to peel back layers of Variable Speed DevOps and show you how you can bring it to your organization.
We will be kicking of our deep dive into Variable Speed DevOps with a series of webinars, the first of which we are announcing today. I will personally be hosting these webinars. What better place to start our deep dive than with Carmen DeArdo and Sanjeev Sharma. We will feature other guests in future webcasts.
Part 1: May 5 – How Nationwide Insurance is adopting DevOps for variable speed IT systems
In the May 5th webinar, we will focus on the ongoing transformational journey at Nationwide Insurance and lessons learned. (Replay available)Part 2: May 19 – Canada Mortgage Housing Corporation breaks down IT silos and speeds up mainframe development
In the May 19 webinar, we will focus on lessons learned at the Canada’s national housing agency in their DevOps and Agile transformation. (Replay available)
Part 3: June 2 – Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study
On June 2 we will discuss the process for quantifying DevOps benefits for your business stakeholder. (Replay available)Part 4: June 25 – Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud
On June 25 we will look into synchronizing mainframe, mobile and hybrid cloud to support end-to-end mobile development. (Replay available)Besides the webinars, we will also feature articles and other content related to the topic. We will build up this new section of our site over the coming weeks, so stay tuned. But wait there is more. We want to hear from you! What is your view on Variable Speed DevOps? Do you have any lessons or thoughts on the subject? If so you can write me personally at editor@devops.com. I would love to hear from you. We can have you write your own post on this, we could interview you for a future article or maybe you could be a guest on a future webcast.
Variable Speed DevOps is going to be important in your DevOps Journey. Join us on May 5th to hear from Nationwide Insurance and stay tuned for additional client stories on this topic.
-
Jez Humble Leads Next Round of Speakers Announced for DevOps Connect @ RSA Conference
The next round of speakers has been announced for the DevOps Connect: SecDevOps event at RSA Conference. Joining the previously announced group we are pleased to announce the following distinguished presenters added to the agenda:
Jez Humble of Chef and renowned author
Jessica Devita of Microsoft
Nick Galbreath of Signal Sciences Corp and formally of Etsy
Dan Cundiff of Target
Chris Walsh of Signal
Sarah Alhafidh of Intuit
David Mortman of Dell
Rich Mogull of SecurosisMost of these people need no introduction to the Infosec and DevOps community. The exact schedule with titles of talks as well as the final wave of speakers will be released next week.
Additionally, Gene Kim and Joshua Corman will be delivering the opening keynote titled: Rugged DevOps: Faster/Safer with Software Supply Chains
It promises to be quite a day of DevOps and security that you don’t want to miss. The event is open and free to all badge holders of the RSA Conference. Unfortunately, there were only 600 pre-registrations allowed and we reached that level last week. However, pre-registration does not guarantee a seat, RSA Conference will seat you on a first come, first serve basis. So come early even if you are not pre-registered.
The event is all day on Monday April 20th. The event starts at 9am but you can arrive early. People may not stay for the full day, so again you should be able to attend even if you missed the pre-registration window. We are just a few weeks away and hope to see you in San Francisco for RSA Conference!
-
DevOps Connect: SecDevOps, how to register if you already registered for RSA Conference
Several people have written asking us how to pre-register for the DevOps Connect: SecDevOps conference on the Monday of RSA Week at the Moscone Center. All registrations are handled by RSA. The event is free to anyone who has any RSA badge. So you can go register for an RSA expo pass and still attend Monday’s event. If you are already registered for RSA, here is how to add DevOps Connect: SecDevOps to your registration.
Steps to register for additional course:
- Log into your registration record
- You’ll be on a landing page with several options. In the Purchased Items section near the bottom, click “Purchase Registration Items”
- On the next page, scroll to the bottom and click Continue:
- The next page will have the Monday activities. The Seminars are at the bottom, check off selection and click continue again.
Obviously pick DevOps Connect: SecDevOps as your activity. Hope that helps. Any more questions about DevOps Connect: SecDevOps or other RSA activities please email us at rsac@devops.com.
-
Shift Left: Can you be left out?
One of the most popular terms bandied about in DevOps is “shift left”. I was at a workshop last month at IBM InterConnect conducted by Sanjeev Sharma and Mustafa Kapadia. They put on a great workshop which was a preview of an exercise they perform in the field for clients. A central theme of their talk was the idea of shifting left to address issues earlier in the development process.
iBM, Sanjeev and Mustafa (both of whom write here on devopsy.kinsta.cloud) are not the first or only people who speak about shifting left in DevOps. Derek Weeks of Sonatype wrote a blog post about it back in September of 2013. Almost a year to the day later, Dibbie Edwards of IBM (and the focus of a good article by George Hulme) wrote a good article about shifting left with continuous testing. Andrew Storms wrote a post here on devopsy.kinsta.cloud some months back about shifting security left in DevOps. Indeed shift left is generally regarded as a basic foundation of DevOps.
Before we dive into what this means to you, we should make sure that we all understand what shift left really means. For me looking at a standard flow of the development/deployment process is the best illustration of this. I think Andrew Storms used a good one in his article, so let’s repurpose it here:
Pay no attention for now to the before DevOps or DevOps rays for now. Take a look at the top line which is the pipeline. You can see the flow of an app from plan to code and all the way to operate. The flow runs from left to right. At its simplest shift left moves tasks further left. Security, continuous testing, continuous integration, continuous delivery are all shifted left.
In doing so potential issues are addressed earlier in the lifecycle. What is this a good thing? A chart from Dibbie Edwards article gives us the obvious answer:
As can be seen the earlier you can get to issues, the cheaper it is too fix them. That alone is a reason to shift left. But also concepts such as addressing security issues before it effects your customers is appealing. The same can be said for many other functions you can shift left.
For me though the question is by shifting everything left, do we just wind up with a big pile at the very left? How do we prioritize all of these left shifted functions? You can only shift left so far before you come to the beginning of the time line. This is not the birth of the Universe where you had a big bang which defies the laws of physics.
At some point can you shift too much left? This is a question I am going to pose to Sanjeev and Mustafa. I also pose it to you the reading audience.
I recognize that the concept of shifting left is not so efficient that everything that can be shifted is in fact shifted left. But as we get more efficient, more and more tasks are left shifted in the process. At what point do we reach the point of diminishing returns?
How do you feel about this? Can we shift too much left? I am interested in some of the different views on this. I am a big proponent of shifting security left, but are there other priorities?
Let us know your feedback.
-
The Docker whale swallows another one, Kitematic
Docker announced another acquisition yesterday, the 2nd one in the last two weeks. This time they have swallowed up Kitematic, a Canadian open source project that makes it setting up Docker on a Mac really easy, Like up and running in 5 minutes easy.
I know some of you may be asking yourself, “I am not going to deploy Docker on my Mac, I only use Mac for my laptop.” Why would Docker spend money or more probably some of their valuable stock, buying an open source tool that lets users run Docker on Mac computers, not servers, not in the cloud. But Kitematic’s popularity is with developers who like the convenience of setting up Docker containers quickly on their laptops so they can develop, test and experiment on the fly. That is Dockers customer base right now.
It is a great little tuck in that gives Docker a good tool that will make their developer supporters happy as they develop apps in Docker containers. I spoke to the Docker folks about this acquisition and they tell me the 3 people behind Kitematic are already on their way to San Francisco to join the team.
The fact that Kitematic uses one of the recently released Docker Orchestration tools is a nice bonus showing what can be accomplished using the Docker tools.
At the end of the day it really is a nice addition to the Docker toolset. It also continues a trend of Docker cherry picking the best of the tools that are popping out of the Docker ecosystem. It makes for a great, quick exit strategy for those folks developing tools for Docker. In the case of Kitematic it was really quick. The 3 founders are barely out of school themselves. But from Docker’s point of view, it makes sense. Buying them early usually means buying them cheap. Usually but not always.
Bigger picture I was more excited about Docker’s recent acquisition of SocketPlane. The company while short on actual code and product had a good roadmap on SDN type of functionality to allow multiple Docker containers to work in concert. There is still a lot of work to be done to make that a reality, but more than a tuck in, Socket Place is a key to Docker success going forward.
There is no doubt that Docker is a darling of the tech world and developers in particular. The issue is when are we going to see Docker move from people tinkering with it to see what is possible, to actual deployments in a big way. Yes there are some real world deployments of Docker. I am not saying there is not. But that is rather small potatoes compared to what the promise holds.
To fulfill that promise enterprises will need to deploy dozens if not hundreds of Docker containers across disparate clouds and infrastructures. These containers will have to communicate and act in concert. That is still probably a little while off, but that is the vision that will see Docker live up to the hype.
The only dark cloud (no pun intended) on the horizon if this type of functionality cannot be engineered in an elegant manner or more likely another container option comes to market with this type of functionality first. Not saying that is going to happen, but Docker buying up these companies at the pace they are inhibits competition from popping up as well.
In any event, we haven’t see the end of Docker acquistions. They will continue building the business by swallowing the best of the ecosystem that is growing around it. There is also a ton of activity on the partner front with IBM working with them on Enterprise Containers, Microsoft working on Azure. In fact I was told in my Docker briefing that Docker themselves are bringing Docker to Windows for Azure in a much faster timeline than even Microsoft.
Stay tuned for more on Docker and containers the rest of this month on devopsy.kinsta.cloud.
-
Happy Birthday devopsy.kinsta.cloud and what a year it’s been
They say it’s your birthday
We’re gonna have a good time,
I’m glad it’s your birthday
Happy birthday to youWow, a whole year. To paraphrase the Grateful Dead, what a strange trip it’s been. We launched devopsy.kinsta.cloud a year ago today with perhaps the naive notion that DevOps was going to really change the way organizations do IT and business. That it was almost inevitable that DevOps was going to move beyond the realm of early adopters and visionaries, beyond startups and Unicorns and see adoption by enterprises and businesses of all sizes and shapes. You know what? We were right!
DevOps has skyrocketed onto the mainstream IT consciousness and we were lucky enough to have a first row seat here at devopsy.kinsta.cloud. We are even proud of the fact that maybe we even played a small part in this adventure.
But let’s be real. It hasn’t been all sprinkles and smiles. We have learned a lot of lessons along the year and usually the hard way. But sometimes the hard way is the best way to learn them. We knew that our audience was going to be a technical group. They would want to hear about and from people who had problems and issues similar to their own and how others solved or addressed the issues. We knew that they liked to find out about different tools that can help you keep the IT machine humming along.
We defined our mission as pitching a big tent for DevOps. I said it in the very first post one year ago today. To me personally pitching that big tent meant that we weren’t just about the existing DevOps community, many of which were early adopters, thought leaders and visionaries in the space. In my mind this group represented only about 15% at most of the eventual DevOps community. I realized that though some people were talking about and instituting DevOps principles for some years already, the majority of our audience was going to be new to DevOps. I wanted devopsy.kinsta.cloud to have a place for everyone interested in DevOps.
That right there has also been the source of some of our biggest mistakes and angst over the year. We definitely took some time finding our legs under us. Finding people with the credibility that others would respect, striking the right tone, fine tuning the mix of articles and topics. At each step along the way we made some missteps. Many in the community didn’t mince words in pointing out what they didn’t like. Others remained silent and just ignored us. We took our lumps for sure, but we just kept putting one foot in front of the other, putting out new fresh content every day.
Many times readers or just people piling on via Twitter took us to task about what people wrote in their articles. We had and still have no problem with readers disagreeing with what an author writes here on devopsy.kinsta.cloud. It is healthy to have debate. But we were surprised that people would think that we wrote the particular post or article. Or that is what we espoused. Just not the case. We don’t agree with what everyone writes here. However we think people have the right to write what they believe in. We think giving people a place to write means not censoring or telling them what to write.
Finally we started catching stride. Since the summer months our entire business has been on a rocket like trajectory. Here are some salient metrics:
1. We are on track for a 100k view month for March. This represents a 100% increase over just November 2014.
2. Our twitter, facebook, Google +, Linkedin following has grown exponentially
3. We have published over 630 articles in the past year, by well over 125 different authors!
4. We have produced or been media sponsor for 10+ events (with many more coming this year)
5. We have produced 8 webinars
6. A DevOps salary survey
7. Fulfilled our goal of becoming the single largest collection of original DevOps related content on the Internet.
8. We published over 50 newsletters and now offer several options on how you want to receive your devopsy.kinsta.cloud news.At a time when media companies like GigaOm are going under. When other media outlets are laying off paid writers, relying on unpaid bloggers, devopsy.kinsta.cloud is adding to our featured writers. At the same time continuing to publish more fresh, original DevOps content than anyone. Other sites have taken to syndicating blog posts from others, republishing stories from elsewhere. At devopsy.kinsta.cloud you can be sure that when we publish a story it is the first time that content has appeared on the Internet.
We have spent a lot of time thinking and planning for the coming year. We think that 2015 and 2016 will be big years for DevOps. We want to make sure we do our part and continue our growth. Look for many new features and new takes on distributing DevOps content and engaging the community this year.
If you look in our about section today you will see a near final draft of our editorial calendar. Our new media kits is also almost ready. You can see a near final draft of that in our sponsor page. Yes, 2015 promises to be even better than 2014. I am sure there will be some missteps this year as well. Hopefully we have learned from our past and there will be less.
Most of all on behalf of everyone associated with devopsy.kinsta.cloud, I want to thank each and every one of you reading this article for your support this year. Without your support, none of the amazing things that has happened so far would be possible.
So happy birthday devopsy.kinsta.cloud. Here is to many more. Also did I mention the first 50 people who tweet with #happybirthdaydevopsdotcom will receive a special edition t-shirt. Thanks again!
-
The best of the first year of devopsy.kinsta.cloud
What were the highest ranked articles by views during the first year of devopsy.kinsta.cloud? We take a look at the top 10 with links back to the original files. What do you think? What were your favorite articles from devopsy.kinsta.cloud this past year?
[seoslides embed_id=”e3bb125a894a” script_src=”https://devopsy.kinsta.cloud/embed-script/the-best-of-devops-coms-first-year/top-10-devops-com-articles/” overview_src=”https://devopsy.kinsta.cloud/slides/the-best-of-devops-coms-first-year/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”The Best of devopsy.kinsta.cloud’s First Year” /]
