devopsy.kinsta.cloud

Category: Blogs

Avik Partner’s Grok APM Uses Machine Learning to Find Anomalies Early On

Machine Intelligence-Driven Anomaly Detection

Machine learning—the science of getting computers to take thoughtful action without explicit programming—is the basis of Machine Intelligence-Driven Anomaly Detection, which is the core capability in Avik Partner’s Grok APM product, according to Casey Kindiger, veteran enterprise software solutions provider, IT automation expert, and founder of Avik Partners.

“Thoughtful action means using the type of faculties that a human being would use to make a decision and to take an action,” says Kindiger, who has more than a decade of experience in designing and developing process automation solutions for companies such as JP Morgan Chase, T-Mobile, and Allstate Insurance. Grok learns from your dev and ops environments and takes thoughtful action to detect anomalies, all in the service of Application Performance Management.

Grok works by analyzing real-time performance data from apps and infrastructure, looking for behavioral bumps in an otherwise smoothly-paved DevOps highway of deployed services and underlying infrastructure.

Grok’s Pre-Event Inferences

“Grok uses common statistical techniques to learn a pattern over a selected period of time in order to build a dynamic threshold of the continuously changing underlying patterns,” says Kindiger. In this way, Grok can establish a sort of dynamic baseline from very noisy patterns, which is something that would typically take a number of person hours of involved statistical and predictive analytics to accomplish.

Grok’s machine intelligence leverages the ability to make inferences based on this dynamic baseline information like a human being would in order to reason out a logical conclusion. Grok does this to detect the slightest of anomalies based on the difference between what reasonably should have happened and what actually did happen. Using this approach, Grok detects subtle patterns of significance in streaming data despite the fact that the data has patterns that are continuously in flux.

But rather than detect when something has gone wrong at a point in time, which is not scalable or sustainable, Grok looks for minute patterns that appear well in advance of any issue that you would normally consider looking at with traditional APM mechanisms, explains Kindiger. Rather than send alerts based on threshold-based exceptions, Grok makes a prediction on what the next data point or the next series of data points will be and then looks at deviations from those predictions, considering whether to flag those as anomalies, according to Kindiger.

Currently, Grok is particularly tuned to analyze streaming data and is, according to Kindiger, data-point agnostic. “We don’t need to teach the system what the context of a particular data point is. The system learns the context of the data over time and the subtle nuances of the pattern that produces over time, and creates the model based on that,” says Kindiger.

Watch Out for That Initial Two Week Delay

If Grok does everything that Avik Partners’ Kindiger hypes that it will, DevOps teams will soon be able to catch and act on infrastructure issues before they grow big enough for end-users to notice.

But Grok does have one wrinkle in its APM armor: it takes time for it to really learn a new customer system and get good at detection. Let’s assume that Grok’s machine learning causes it to get better at detecting anomalies in a given set of infrastructure over time. That means that there’s a point, at the beginning, given a brand new customer when Grok only starts to learn. At that point, Grok isn’t very good at knowing what’s anomalous compared to what’s normal for that infrastructure because Grok has no foundation for that particular system.

“Grok will take some time to learn the nuances of when to escalate an issue. We’ve learned from experimentation that it gets pretty good after ingesting two weeks’ worth of data,” says Kindiger. Because Avik Partners initially targeted AWS, it has taken two weeks of CloudWatch data and fed that to Grok to provide it with some backdrop so that when Grok goes live, it won’t be learning this environment entirely anew.

November 3, 2015
For more mobile wins, enterprises must find their MVPs

The demand for enterprise mobile apps just isn’t letting up. The research firm Gartner expects that by the end of 2017 enterprise user thirst for mobile apps will be growing five times more quickly than internal IT organizations can deliver those apps. And a recent Opinion Matters survey found that enterprises are already hitting deep backlogs, with 85% of enterprises surveyed reporting that they already have a significant mobile app development backlog.

Such a backlog, as we’ve covered earlier, suffocates an enterprise’s ability to innovate and be competitive. When enterprises take too long to give development teams the app specs they need, and those apps take weeks and months to build and ship, the enterprise just lumbers along in its digital efforts. That means worker productivity lags, too. Most of the time customers aren’t happy with their experience, either.

Why are enterprises having difficulty fulfilling their app demand? There are a number of reasons, notably that enterprise development teams often work the way things were accomplished a decade ago when IT was more centralized. First, the app needs approval from IT and then timelines are set. And the app needs to be prioritized along with everything else on development team’s plate. When apps are approved, everyone tends to try to shove his or her pet features into them and the apps end up trying to achieve too much right out of the gate.

Enter the MVP

The result of all of this, of course, is that the time between the app request and its delivery is extended considerably, and when the app finally does arrive – if it doesn’t meet the required needs or is less than optimally executed – a big and time-consuming effort turns into a big and costly setback. It’s one of the reasons why so many enterprise mobile apps fail, with 50 percent of respondents to a recent survey saying that their mobile apps failed because of poor user experience.

It’s also one of the reasons why more enterprises are embracing the Minimum Viable Product, or MVP, as a way to get try to get apps with the features users need as quickly as possible, while not investing too much time in apps that users don’t desire. “In the strictest definition of MVP, it refers to a product that delivers the highest ROI relative to risk,” says Scott Amyx, CEO at Amyx McKinsey, a smart wearables and Internet of Things strategy and development agency.

What does that mean, practically, to CIOs and development teams trying to develop more apps that are more on target to user needs? Asaf Yigal, cofounder and VP of product at data analytics platform provider Logz.io, says it means that developers should start with a minimalist, but useful, definition of the app that is to be created.

At Logz.io, Yigal explains, the company develops with an agile methodology. “It’s critical for us to be able to define the MVP before we start a project,” he says. “There are two key objectives when defining a MVP. The first objective is that the majority of the users need to be able to benefit from a new feature – this means that we don’t address edge cases in development at all. The second objective is that we need to be able to analyze how users will be using the new feature. We are a data-driven company, which means that we log all relevant events in every feature we develop and build internal dashboards that display how users are interacting with a given feature,” he says.

Small teams, small apps, tight focus

Greg Archbald, founder & CEO of oil and gas industry software provider GreaseBook, has worked with dozens of oil and gas companies, ranging in size from those with tens of billions in revenue to those with less than one billion in revenue. Archbald explains that while the “super majors” of the industry have plenty of success extracting hydrocarbons, they don’t necessarily excel in building software. “Even the companies that have managed to land themselves some really strong development talent tend to struggle with project scope,” says Archbald.

Why? It’s the sheer number of people that become involved in the development process, he explains: ”I’ve seen first hand how layers of management, engineers, and production supervisors (all with the best intentions) become involved, and this is where issues begin. Everyone needs the app to do something different, and pretty soon feature creep settles in.”

This is especially true for development teams that find building systems easy, but dealing with people more difficult. “For much of software to be successful, it must focus on the human elements, not the technical. And, most larger companies don’t realize this soon enough and ultimately set themselves up for failure,” Archbald says.

So who’s going to keep app development on track? It could start with learning when to say “no,” Archbald says. “This is very tricky because, as part of a development team working for a large company, you’re paid to develop, not to tell upper-management “no,” he says. But to be able to succeed with the MVP and clearing app backlog, it’s about clearing both unnecessary people and features. “The word ‘no’ is exactly what MVP stands for. And at larger companies, a successful MVP isn’t just about a limited set of features, but also about a limited number of people involved.

“It sounds counterintuitive, but many projects in the development succeed not in spite of the limitations but because the limitations were put on them. Limitations of the amount of input, manpower, beta-testers, and even funding – all of which are unheard of at the enterprise level – force a team to figure out more creative solutions.”

Jordhy Ledesma, CEO at creative design, information architecture, and custom programming consultancy Information Providers would likely agree. “Keep the development team to less than a handful of teammates. Develop using the SCRUM project management framework (which advises to code in sprints and ship functionalities in batches) and limit the project duration to less than six months,” says Ledesma. “What is sometimes misconstrued by the DevOps community is that MVP is about a tangible, minimal product more than a methodology to leverage. In other words, it’s an iterative process that helps us to refine our concepts, prototypes, data, analyses, and learnings to deliver high value to our target customers. It’s a framework.”

It’s not just about enterprise software; as more things and devices become interconnected, it’s going to be even more important that enterprises reduce risk with apps. “Our agencies work with both large enterprises and startups. When they come to us to conceptualize and develop wearables and IoT products and services, they almost always start with an aspirational vision. Sometimes, that means a laundry list of sensor technologies or data analytics capabilities,” explains Amyx.

“We work with them to understand, from the customer perspective, what is the biggest pain point and then to focus on delivering a focused solution that addresses the top problem statement. After we learn from an iteration, we do it again to incorporate customer feedback into the product roadmap. A tight MVP methodology turns a potentially daunting process into doable mini-sprints while helping our clients to focus. They are often surprised at the nth iteration how their product/service is vastly different from what they had originally envisioned,” Amyx says.

November 3, 2015
Combining SecOps and DevOps

Security has to be top of mind for most any company that is moving, or has moved, to the cloud. And, businesses know they need to act swiftly to ensure that any new products or services they’re dreaming up do not expose them to risk.

How can they do that when the fast-moving nature of the cloud is leaving proper security practices in the dust? The problem today is that today’s security solutions are proprietary, too slow and take too many resources.

Bottom line, the security model that has served most businesses well was never built for speed, and is simply unsustainable for opportunities in today’s cloud-centric world. Today, security solutions must be agile, lightweight, loosely coupled and extensible.

On the front lines at various companies you’ll see a new type of cooperation – where two teams most directly involved in a potential solution, development and security – are breaking down the traditional (and often opposing) silos and collaborating more openly to drive secure innovation from the start.

We’re seeing a new “marriage” of SecOps and DevOps that creates a whole new mentality for driving innovation inside and outside of organizations. This new mentality allows security and DevOps to find common ground to make it easier for organizations to align their security goals with the delivery of their products at today’s rapid speed of business.

While businesses are changing internal structures to address cloud security, there are also a number of new solutions that can be deployed against a company’s clouds and deliver security intelligence back to the DevOps teams.

These kinds of tools are especially important for start-ups and SMBs that face unique challenges securing their businesses from cyber attacks and preventing data breaches.

By encouraging greater collaboration between security and DevOps, and relying on outside solutions to assess and identify potential threats as new products and services are developed, businesses of all sizes can feel a higher level of confidence that they’re addressing security concerns by enforcing industry-leading security practices every step of the way.

About the Author:/Tim Prendergast

Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

November 3, 2015
Mapping the Manager’s Journey to DevOps and Continuous Delivery in the Enterprise

Software development methodologies like DevOps and Continuous Delivery continue their rise to household name status. This is due in part to the increased mainstream media attention they get, but also from the diverse range of enterprise organizations like Target, who are announcing large investments in it, to GE who has shared one of their division’s success story with the world.

“The journey of a thousand miles begins with a single step.”

Daoist Chinese philosophy is probably not the first thing you would associate with improving software delivery at your organization. But in reality, it rings true as enterprise IT managers begin the daunting task of transforming the software delivery process. So why set out on this path?

One reason why IT organizations are moving to Continuous Delivery is to gain the ability to provide timely user feedback to the developers so software can better meet their demands. Gary Gruver, author of the enterprise IT best seller, A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware and the former Director of LaserJet Firmware at Hewlett Packard lead a DevOps transformation in 2008, back when this portmanteau was barely on anyone’s radar. Up until that point, the group—comprised of about 800 developers globally—was averaging two releases a year. The vast majority of the group’s resources was swallowed up by the porting of existing code to new firmware and the process of check- it was taking up to eight weeks for a developer to learn whether their code change worked or not! The lag time introduced in the process of fixing those bugs was obviously a big detriment to their productivity and it prevented the developers learning what mistakes they might be making.

Continuous Delivery is about continuous improvement—it’s taking one step at a time on this journey that ultimately gets you where you need to be. In an interview with Alan Shimel, editor of DevOps.com, earlier this year, he said “each organization is different. You really need to start where the most pain is. And one of the things that DevOps causes you to do is do things more frequently. And what you’ll find is your organization has been brute forcing its way through the same issues for years. And as you start to increase the frequency, you’ll have to start fixing that.”

Each organization is obviously different. For executives who have a better sense of the big picture and understand less of the day-to-day details, it’s important to have a clear picture of the existing development processes before beginning.

But, how do you translate these process details into something that improves at the scale necessary for the enterprise? Are there metrics that are important to focus on along the way? What type of team structure do you need in place? What’s the best process? Kicking off a DevOps transformation takes some effort but companies who embark upon this are seeing notable results. Fortunately, Gary and Tommy Mouser, Director of Test Automation at Macys.com can help make your journey easier. They have distilled their real-world knowledge of doing this in their new book, Leading the Transformation: Applying Agile and DevOps Principles at Scale.

On November 17th, my colleague Andrew Phillips, Vice President of Product and active developer/DevOps evangelist in his own right, along with Gary and Tommy will be sharing their experience and practical advice for kicking off your own DevOps/Continuous Delivery journey. It’s an interactive panel webinar so questions are strongly encouraged! As an added bonus, just for attending you will receive the first 2 chapters from Gary and Tommy’s new book. And for those with really interesting questions, we’ll send you the whole book! I look forward to you joining us for a lively discussion on the 17th!

Register Today!

About the Author/Heather Moses, Vice President of Marketing

Heather heads marketing for XebiaLabs. In this role, Heather drives global marketing strategy and operations for the Company. As part of the senior leadership team, Heather is responsible for market direction, brand evolution and market outreach best practices.

November 2, 2015
5 Tips for Building a Winning DevOps Culture
Despite our cognitive prowess, humans are just like other animal in the food chain. We follow patterns of behavior based on survival. If food is safe to eat today, we’ll eat it tomorrow. If we can navigate a road without getting hurt, we’ll do it again and again.

This explains why change is so hard. Evolutionary magic has taught us to avoid stuff that could harm or kill us – in life and even in business.

But the business jungle is changing faster and far more radically than ever before. The pace and ubiquity of technology has resulted in once sturdy business models being brutally felled. Now we must move out of our comfort zones – or get eaten alive.

Businesses now require regular and sustained innovation, but this is problematic for many organizations more used to operating in safe mode. For them, fear of change reigns supreme – even when the company is losing market share and talent is leaving in droves.

The situation is recoverable when leadership commits to building culture of innovation. This is especially important in IT, because it’s here where innovation now starts and ends. To this end, organizations are rushing to embrace Agile and DevOps – the practices of choice for rapidly delivering high quality software.

But when it comes to culture nothing is easy. Here are five tips to help ensure success:
1. Avoid Building Elitist DevOps Teams – the natural tendency with any new initiative is to build out a separate team. This means bringing in outside experts, cherry picking what’s seen as the best internal talent across development and operations, and then operating distinctly from the rest of IT.
It must be remembered that DevOps isn’t a function, but a model in which development and operations collaborate. Therefore building a separate team is just creating another silo, which because of the “elitist” association could create even more friction.

DevOps teams can valuable during early stages of a program, but only then as a transitional practice. In these case members of the team are chartered to spread knowledge; building the bridges across the organization and then disbanding once practices start to take hold.
1. Cull Elitists and Destructive Narcissists – a strong DevOps culture is based on collaboration and empathy; sharing success and learning from failures. If, however, initiatives are led by individuals who strive for personal glory and kudos at the expense of everything – especially staff morale and wellbeing, then there’s a problem.
Doubly difficult is the fact that people in this category are energetic extroverts; appearing ideally suited to spearheading important cultural change initiatives. But remember this – energy doesn’t always equal intelligence, so seek out the big thinkers over the big talkers. They’re just as likely to be introverts, only netter equipped with the intellectual persistence and the emotional smarts needed to help build a thriving culture.
1. Reward Wishful Thinking and Craziness – ever wondered where great business ideas from the likes of AirBnB came from? Probably from folks challenging the status quo by creating problems customers didn’t know they had (and then solving them with software)– like – what if we could take that wasteful spare room you have and turn it into a cash generating mini-hotel?
In a DevOps context, we can use a similar approach. Looking at the ways processes are being conducted and then suggesting counterintuitive alternatives. For example, what if our change management process is completely wrong – can we find ways improve automation for agile development? Why should we wait for production monitoring – what if we build it during coding and testing to increase resilience?

In a strong DevOps culture suggesting ideas is openly encouraged and rewarded. Without it, great ideas get lost or unnoticed, or worse, get belittled and smashed by those elitists and narcissists.
1. Have a Healthier Respect for Failure – if you want to kill DevOps before starting, go ahead and talk up past failures – like – “We tried agile five year ago and it was a train wreck –DevOps will be no different!” Glass half-empty thinking like this is detrimental because it put the brakes on talking risks and exploring a profitable digital future.
Nobody likes talking about failure, but the key to making progress with DevOps is to accept that mistakes happen all the time. What’s key is treating every fail or screw-up as a learning point. That way we stop talking about things that didn’t work before, and start describing them as lessons which help build a brighter future.

Taking the fear out of failure needs a lot of executive support. Management should begin a parallel process of rewarding sensible risk taking and removing any structures and incentives that stifle innovative thinking.
1. Walk the People and Process Pipeline – even with great tools, DevOps won’t deliver anything if sub-optimal processes or organizational friction persist. In most cases defects and delays can be put down to people enforcing rigid policies or relying on manual and error prone handoffs.
One good practice taken from the world of manufacturing is taking a “value walk” across your own software factory. This involves spending time interacting with people as they conduct their jobs (develop, test, release etc.) – not to point fault, but to understand any situational stresses that increase waste and technical debt, and could be remedied from automation.

Carving out opportunities from the digital chaos and disruption is the perfect place for DevOps. But don’t get carried away – change is hard. Make sure you have the right leadership, practitioners and counterintuitive thinking needed to start your transformation journey– and keeps everyone onboard.
November 2, 2015
The Growth in Data Center Uses for Shadow IT

Shadow IT is casting a long shadow over IT departments as more organizations react to changing demands from their customers, partners and regulators. Groups and individuals outside of IT are taking matters into their own hands by tapping new cloud-based applications and hosted data centers.

Shadow IT involves any purchase of equipment, software or data center resources for uses outside of production IT. These purchases usually fall outside the IT budget as well. In many ways, this trend effectively cedes the influence and control of CIOs and IT managers to others within their organizations. According to at least one bold estimate, shadow IT is set to make up 90% of all IT purchases by 2020.

becoming faster and easier to acquire cloud resources that take longer to get with traditional IT processes. It’s therefore hard to hold back the growth of shadow IT. For example, a test engineer who needs some servers for performance testing. Or a product manager who needs some machines for internal training. Setting up a few AWS instances could take a matter of minutes – you just need a credit card. That seriously lowers the motivation to start requesting those resources from IT, explain why you need them, get approval, and then wait for manual allocation or completion of the purchasing process. As everything gets faster, online, and more automated, the line of business cannot afford to wait.

Let’s examine the main uses of shadow IT to get a better understanding of what is happening.

Uses Cases for Development and Testing

Developers and test engineers are under huge pressure to be more agile. Even in organizations that we would never think of as “fast,” the pace changes rapidly. In heavier organizations that spent years establishing well-groomed IT processes, the dev/test consumer’s patience is running low. We are officially at a point where swiping a credit card and expensing an AWS instance has become easier than opening a ticket to request a virtual machine. As DevOps and automation cross borders and become mainstream, the need for speed makes Shadow IT thrive.

Uses Cases for Sales Enablement

Another line-of-business activity that’s implementing shadow IT involves the sales enablement process. This includes demos and proofs of concept, along with internal and external trainings, or customer support services.

Until lately, most demos and proofs of concept were the responsibility of sales organizations, and such work was generally performed beyond the purview of IT. Now fewer companies are staging demos and proofs of concept at customer sites. They are adopting hosted data centers and web-based cloud services that customers and sales teams can access remotely through self-service.

In recent years, many of these sales demos have been conducted at resellers and integrators, or by building a lab at a hosted data center where the infrastructure and software is housed.

Uses Cases for Partner Enablement

Shadow IT is also catching on for partner enablement to facilitate software development sandboxes, certifications, and testing of software-defined networks. Many industries depend on such product ecosystems for their long-term success. With software-defined infrastructure, the software can be easily integrated and controlled using outside tools.

Most major hardware and software vendors are developing new partner labs. Members of the partner ecosystem can certify performance against the vendor’s equipment and interfaces without making big capital investments in the infrastructure themselves. Some examples include Cisco DevNet and Salesforce’s Force.com.

Shadow IT Continues to Grow

The organizations that adopt agility and DevOps are no longer the leanest and most cutting-edge. They can’t get away with a single Amazon instance. They need support for more complexity, more configurations and more context. They need to better mimic production, because more is at stake.

As more lines-of-business in these organizations need to be faster, it’s becoming more challenging for IT to meet their needs with the Production IT toolbox – whether it is for development, testing, security certifications, demos or support.

These kinds of use cases for shadow IT are on the rise, meaning shadow IT will continue to be a growth market for years to come. Whether or not shadow IT will consume 90% of all IT budgets remains to be seen, but it will definitely make up a significant portion of IT spending until production IT changes its approach.

About the Author/Maya Ber Lerner

Ber Lerner began her career with QualiSystems in 2007 and has steadily risen through the ranks in various roles starting as product manager, director of channel development, director of sales for APAC and Israel, senior director of international sales and, most recently, VP of sales, international. Ber Lerner holds a Bachelor’s degree with honors from Tel Aviv University in Biomedical Engineering.

November 2, 2015
How to Handle DevOps Microservices (Hint: Carefully)
Given the dizzying amount of best-of-breed tools that can be involved in the development pipeline, a well-written microservice comes to the rescue with just enough code to keep things running. But too much of anything is never good. Here’s how and when to use microservices.

Microservices are all the rage right now: these mini-apps are being used to integrate distributed applications that can be modified more easily. Microservices act like the glue, holding together processes and systems in the DevOps automation workflows. This means faster, more automated cycles, better implementation of continuous delivery and increased visibility into DevOps processes and deployments.

For developers and testers, who generally love the best-of-breed approach of using whatever tool they prefer for the job, microservices allow them to do that by affordably connecting many different open-source and commercial tools in the DevOps pipeline. While some of these tools have built-in integrations to other popular tools, those integrations may not be exactly customized for your needs. Asking the vendor to build custom integrations for you can be cost prohibitive and may not be feasible within the time frame your organization is looking to implement.

So with microservices, development teams have the flexibility to build their own tool stack and integrate everything to achieve full visibility into the development process. Equally helpful, REST APIs are super easy to work with compared with legacy APIs; developers can handle writing microservices without specialized expertise in the products that are being integrated. These are just a few of the extremely powerful advantages of the microservices approach.

Yet as with every other cool technology, there are a few hitches, as follows:
1. Hard to handle. Microservices depend upon vendor APIs, and when those change, the service will break. Then, you’ve got to rebuild the service from scratch. That is a time-consuming task that detracts from the main job at hand: writing and refining code. In an environment with hundreds of microservices, pretty soon, you’ve got developers spending the bulk of their time updating those pesky mini-apps in your devops pipeline instead of building new user features. Costs escalate and timelines slip.
2. Slapdash processes. Let’s face it, when you’re writing a microservice just for your team, you’re going to do it as quickly as possible, thereby skipping a few steps that can make the microservice less fragile. A vendor, meanwhile, writes a micro-service to help hundreds of customers – therefore, it’s got to be bulletproof. The internal approach for integration through microservices can be more prone to breakage. Once one service breaks, there is the inevitable domino effect with other integration points, meaning down time in your development process.
So, now what? It’s possible to make all this a bit easier. First, make sure that you’ve got the economics straight. Will developing microservices as your integration strategy be cheaper (factoring in staff time) than having vendors do it for you? If cost is not the main consideration, do the benefits of having a custom-built DevOps tool stack outweigh the complexity issues including downtime risks when a service breaks? Is there a clear-cut benefit from having a custom integration over taking the vendor’s not-quite-perfect integration? Do the analysis before choosing the microservices path – and remember to tie all this back to business benefits.

Here are some ways to reduce the complexity of microservices:

Go hybrid: In most cases, organizations will find that using a combination of vendor integrations and microservices is often the answer.

Outsource: For business-critical applications, it’s not a bad idea to let an outside development firm handle the microservices portion for you. That will reduce your risk and free up your developers to focus on building products not managing integrations.

Tools and languages: Choose languages for writing microservices that work well with REST APIs, such as Python and Ruby. As well, keep an eye out for tools that can help when you’re doing this in-house, such as Zapier or TaskTop. We expect those automated options to only grow, as companies expand their use of microservices and containers to optimize their DevOps operations.

About the Author/Kevin Dunne

Kevin Dunne is the vice president of strategy and business development at QASymphony. He has a deep interest in the emerging trends in software development and testing. Kevin joined QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. He can be found online at LinkedIn and Twitter.
November 2, 2015
All Hallows Eve in DevOps

You never know

Here are some other ROELBOB’s you might like

A Containers Angst

The Pink Slip

Systems Orchestration

Hot off the Press – Other great DevOps.com content

The DevOps Dozen

DevOps Must Also Mean OpsDev

Upcoming DevOps.com Events

DevOps Connect: cdSummit SoCal

Webinar: Testing Infrastructure as Code with Security: 5 Practical Tips

— ROELBOB

October 30, 2015
DevOps Chat: Sunil Rajasekar, CTO of Lithium

Continuing our DevOps Chats, Leadership Series I recently sat down with Sunil Rajasekar, CTO of Lithium.

As Chief Technology Officer, Sunil oversees core product, development and delivery of Lithium’s enterprise platform. Sunil is a seasoned technology executive who brings more than 15 successful years of enterprise, small business and consumer software experience. Prior to joining Lithium, Sunil served as Vice President of Engineering, Operations and Program Management at Intuit Financial Services and held a variety of senior roles in the Intuit Small Business and Central Technology groups. His passion is building innovative and successful web and mobile offerings that companies and end users love. Previously, Sunil worked at Oracle, Cisco and several startups.Sunil holds a MBA from the University of Toledo.

Sunil and I had a nice chat about what it means to lead transformation at at organizations today using the many tools and options available. Regardless of tools though, Sunil emphasized what leaders have to do to enable transformation. It was a great chat that I hope you enjoy!

[soundcloud url=”https://api.soundcloud.com/tracks/230736526″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]
Alan Shimel:                Hi, Alan Shimel at DevOps.com here for another Dev Ops Chat in the Leadership Suite. Today’s guest is Sunil Rajasekar, CTO of Lithium, Lithium Technologies who are helping people with their social customer service software and social software in general. Sunil, welcome to Dev Ops Chats.

Sunil:                           Thank you, Alan. Happy to be here.

Alan Shimel:                So Sunil, for those of our listeners who may not be familiar with Lithium, can you give us just sort of a quick background on what it is Lithium does?

Sunil Rajasekar:          Sure. So we’re in the business of helping companies engage with their customers in new patterns and what they’re dealing with now, right? Where consumers have all the power, they have access to all the data that they need and companies don’t own their brand anymore. The consumers are the ones that determine the brand. So we help companies deal with this environment in this reality that they are dealing with by helping them engage with their customers at scale through social channels and also facilitate conversations between customers.

Alan Shimel:                Sure. And Sunil, I thought this was such a great topic for our Leadership Suite because I’m sure many of our listeners are grappling with this issue right now. There’s just a new way of doing things including a new way of engaging with customers. A new way of presenting your brand in the marketplace. And so much of it is wrapped around the social media and social communications that we see today. And companies who aren’t grasping this are quickly becoming dinosaurs. People tend to think of it’s the Unicorns, the Googles, the Facebook, the Twitters who are getting this or the startups. But that’s not really who your customer base is, is it Sunil? You guys work with some large customers?

Sunil Rajasekar:          We do, yes. So we work with a wide variety of customers. We work with companies that have been a really long time so AT&T, Telstra, Cisco, HP; these are all customers of ours and they’ve seen a lot of success _____ [inaudible]. And we do work with a lot of the new companies that have been born in the “digital age” as well. So we work with companies like FitBit. We actually do work with Google, they are huge customer of ours as well. So we actually have a variety of customers across the spectrum, those who are new who get this new reality and those who get this reality but are adapting their business to adjust to it as well.

Alan Shimel:                Sunil, I’m sure we have some people out in our audience today who are leaders in their respective companies and they are faced with an evolve or die reality. What, as a CTO, as someone who founded companies and so forth and you are background, what would your advice be to them?

Sunil Rajasekar:          I would say three things, Alan. So one is make sure you have a diverse network. And so and the reason I bring that up first is we were talking about this earlier as well. Things are changing so fast in the tech world right now, it’s hard to keep pace and it’s hard to know whether it’s a passing trend and what’s here to stay. And it’s hard to digest all this data and then figure out the _____ [inaudible]. And if you’re going to try to do it by yourself, I would say it’s going to be next to impossible. And if you stick to just your countered network, right, the people you work with day in and day out, you’re probably getting the same level of information and you do end up with a group think type of situation. So making sure that making the time to engage with people in other industries, similar roles who are probably trying to figure out the path forward just like yourself. I think that’s the way to do it. You want to make sure you’re plugging into these other networks, you’re sharing your learnings and learning from others as well. So this is something that I’ve made a conscious effort to do in the past couple years and it’s been invaluable so I would say that’s one.

In the second thing is, it does boil down to good old change management as well. Yes, there are some great trends that are out there and you should probably thinking about implementing it. But at the end of the day, you’ve got to know how to take this trend or new technology or new process and make it work for your organization. And that’s good old change management, right? So you need to know about your team. You need to know about the business needs and make sure that you can tailor whatever transformation you want to drive to the needs of your company. So what does boil down to change management?

And then the third thing I would say is just resilience. And anybody who has made it up the ranks, they probably know this already but it’s a good reminder. Anytime you’re driving a large transformation, there are going to be challenges along the way. And you need to make sure that you are resilient and your team is resilient and the rest of your executive staff has bought into the transformation you are driving and they come here to support you and there are roadblocks as well. So as those are the three things. Make sure you have a diverse network, focus on change management and make sure you don’t forget about being resilient.

Alan Shimel:                Sure. Sunil, I have questions I’d like to follow up with you on two of those points you’ve made. First of all, in terms of a diverse network which as you said you have pursued over the last couple years, what advice can you give our listeners on what kind of group should they be looking for? Where do they find them? How do you make that a reality?

Sunil Rajasekar:          Sure. So there’s three ways I’m going to do it and there’s a plan to do it, I would say, here as well. One is of course your personal network. There are people you’ve worked with in the past who you admire, probably have gone on to do other things and have other experiences. So making sure that you really cultivate your network and you reach out to people and check in and if you have a situation you’re dealing with, reach out and ask for advice. Or if you’re contemplating a big technology decision or a business decision, reach out to these folks who are in your network and get the advice.

Another thing that we’ve done is we’ve set up a technology advisory board so we have course have the board for the company. We’ve got a special technology advisory board that we’ve set up as well. And this has people from companies like Google, LinkedIn, Netflix. So some very, very strong background for all these folks and we’ve use this technology advisory board extensively for some key decisions that we’ve made. So that’s been invaluable.

And then the third thing I would say is plug into meet ups that are going on. Chances are whichever city you’re in, there are a ton of tech meet ups that are going on and if there’s not that many, start one and get people from other companies to come and share their learnings on different topics. So we have a _____ [inaudible] ops meet up that we set up and we meet pretty regularly in our office and it started off as a small thing and now we have members who participate from again, the Googles of the world, the Air B&Bs of the world and we have over 1000 members. And that’s been great as well.

Alan Shimel:                Yeah, no, that’s fantastic. Sunil, jumping to one of the other points you made which was about change management, so something else – just my opinions, observations and advice is sometimes it’s about embracing change. Too many people look at sort of the new technologies, the new ways of communicating, the new ways of doing things as oh my goodness, I’ve got to learn something new. Or this is changing what I do and no one likes to change what they are used too. I get all that. But sometimes embracing change is what makes the difference. Right? Embracing this change, looking at it as how can I make it a positive rather than just defending my turf if you well? Way too often people are just defending their turf, it seems, instead of embracing the change and running with it. And that would be my advice as well is don’t think of these changes as yet another thing you have to do. Think of them as ways that are going to make your life easier, make you more successful, make your organization and those around you more successful. So I –

Alan Shimel:                That’s part of it.

Sunil Rajasekar:          That is so true, Alan. There was a time when I think leaders were looked up to for stability and making sure that things stayed stable. But I think that paradigm has changed. In this time and age, the leader is looked at primarily for their ability to predict change and guide the organization on the path that they can adapt to this change and be successful in the future as well. So as a leader, that is one of our key responsibilities, looking at what’s coming around the corner and making sure that you are guiding the organization in the right direction. So it’s changed in my opinion.

Alan Shimel:                Absolutely. Well, Sunil, the problem with changes sometimes it moves too fast and so does the time we have for our web chats unfortunately. We are well over our 10 minute kind of target so were going to have to wrap it up. But for people who want to find out more about Lithium and kind of how you guys can help, where can they find you on the web?

Sunil Rajasekar:          Oh, it’s easy; www.lithium.com. And from there, you can connect to a lot of good information and hopefully you know me as well; if you have follow-up questions or comments.

Alan Shimel:                Fantastic. Sunil Rajasekar, and I may have messed that up; I apologize. Thank you for appearing on this episode of Dev Ops Chats for the Leadership Suite. And continued success with Lithium.

Sunil Rajasekar:          Thank you very much, Alan. Thanks for having me.

October 30, 2015
Piecing Together the Elements of DevOps Transformation
Sometimes when a concept as transformative as DevOps comes along, it’s easy to forget that subsequent adoption represents a highly complex and iterative process.

While it’s clear that some organizations are already deeply leveraging DevOps to embrace the Applications Economy and Digital Transformation, it’s no surprise that for many organizations this process has only just begun.

So where have today’s organizations made the most progress, and what are the most significant challenges that practitioners continue to face?

To get a better fix on the current state of DevOps maturity and isolate the specific areas where most organizations must continue to focus their attention, researchers at Freeform Dynamics have created a matrix of practices key to measuring progress, dubbed the “DevOps Jigsaw”.

Drawn from the same survey data recently surfaced to profile leading-edge “Digital Disruptors” that have already wrapped their arms around DevOps advancements, this latest report, sponsored by CA Technologies, offers a crucial view into the current environment.

It’s worth noting that of the 1000-plus respondents included in this particular data slice, the vast majority, or 80%, are categorized as “Early or Limited” adopters, with only 20% recognized as “Advanced”.

Of the nine individual DevOps “puzzle pieces” examined in the report, experts grouped these efforts under three umbrella categories: “Key Enablers and Controls”, “Skilled and Collaborative IT”, and “A Business Led Approach”.

Business Led Approach – This subset encompasses strategy and objectives required to tie DevOps adoption to larger business goals, including:
- Well-defined strategy and objectives – In this key planning stage of DevOps transformation, 55% of respondents said that much of their work is “already done”, while another 36% charted it as “a work in progress”.
- Business stakeholder education – Roughly 33% of respondents said that this informative step in DevOps adoption is complete, with a larger majority of 43% noting that they are still working to advance this process.
- IT-business alignment of priorities – In getting stakeholders on the same page around business and DevOps direction, some 37% indicated that they are nearly done, with 43% of still attempting to embrace these efforts.
Skilled and Collaborative IT – This genre of requirements covers the cultural and automation capabilities necessary to foster DevOps success, including:
- Relevant IT knowledge and skills – Related to the development of DevOps expertise, 39% of respondents feel that they’ve already made the grade, with 40% conceding that they have more homework to complete.
- Cross-functional IT processes – As much as any related initiative, DevOps mandates tighter internal collaboration, with only 35% of respondents having achieved this goal, and 45% citing the need to keep pushing.
- Cultural harmony within IT – On a related note, DevOps teams must work together smoothly to succeed, with a mere 29% of respondents claiming such parity, offset by 46% that acknowledge a teamwork deficit.
Key Enablers and Controls – This category of DevOps maturity addresses key issues of technology, solutions acquisition and IT security, including:
- Right infrastructure and tooling – Efficient tooling and infrastructure are another key DevOps enabler, with some 37% of respondents feeling good about their current solutions, and 42% still looking for answers.
- Right suppliers and support – In sourcing the products and services required to advance DevOps process, only 33% of respondents said that they’ve found the right providers, with 46% still seeking additional help.
- Security and compliance measures – No area of IT can be addressed without consideration of security and audit issues, with 35% of respondents comfortable with their controls, and 46% in need of added defenses.
Given these overwhelming results, it’s clear that most organizations still have a long way to go in achieving greater DevOps maturity; at the same time, there’s also plenty of evidence that today’s practitioners have already made a good deal of progress.

Comparing your efforts to these established “DevOps jigsaw” puzzle metrics should help inform future strategy in creating a more cohesive framework of people, process and technologies, and deliver DevOps success.
October 29, 2015