devopsy.kinsta.cloud

Author: contributor

Buzzword abuse: The anatomy of a DevOps Engineer
Once, people used the word genius only when describing someone who really was a genius. Someone with extraordinary intellectual and perceptual capabilities. Today every parent uses this word to describe their, likely cognitively regular child – and this term has lost any good taste. I find the same trend holds true for DevOps. And yet, that doesn’t stop everyone from saying the word DevOps, a lot (and more often than not, in a completely wrong context).

The Problem

Many recruiters are now looking for “DevOps Engineers”. The demand for “DevOps engineers” has grown exponentially over the course of the last few years by thousands of %, just a small trend graph from indeed.com, and snippet from Google.

We constantly hear about companies building, “DevOps Teams”, and developing “DevOps Tools”. Everyone wants “DevOps” but have no idea what it means.

The short definition of DevOps is the ultimate business-requirements to customer to business-requirements cycle (often referred to as the best “development to production cycle”). How this would look in code:

(Of course, this snippet presents the problem very broadly and doesn’t take serious bugs into consideration)

All of this, aside from the development process is expected to happen automatically, not affect users at all, and have monitoring that is so exceptionally smart that it always points to the exact problem. Hmmm. What’s described above, is of course…. utopia.

Reality Check. Most companies are more likely in the camp that:
- runs tests manually or not at all
- monitors the wrong things
- reacts to the wrong problems in the wrong manner
- doesn’t improve work processes
- keep doing the above in iterations and trying to set out fires while more fires appear.
- more bad stuff…
DevOps aims to solve these problems.

It is a culture, in which people work together to improve the product delivery cycle.

At its base, it requires good collaboration/communication (with the other teams), familiarity (with the system), control (over features and failures), short dev-to-prod cycles (this isn’t mandatory, but can help to prevent major bugs), and quality testing (‘nuff said). This is practically a great analogy to a good relationship except that it also requires automation (to make all of the above possible), which is something you should probably refrain from in your relationship if you want your belongings to remain inside the house.

The Perceived Anatomy of a “DevOps Engineer”

Let’s look at the following job descriptions.

DevOps Expert

See anything… strange about them? Yes, they want a God.

The Dream Errr…”DevOps Team” is basically a group of:
- Linux Experts (preferably all distributions in the world)
- Coders (preferably Python, Ruby, Perl, Bash, Batch, Powershell, Powerpoint…)
- Adept at CM, CI, CD, NBA and NBC (So they must know Chef, Puppet, Jenkins, Hudson, Travis, Git…)
- Have vast knowledge in Cloud (like.. in the sky?)
- are familiar with Databases (Including high availability, disaster recovery, fault tolerance, fail-over… something like the average marriage)
- Know Storage (WTF?)
- Know Monitoring (Nagios? REALLY?!)
- Know Networks…
- Know Big Data (the bigger, the better)
Bottom line, they are supposed to be a group of people who know everything, can do anything, yet do not develop the application (That’s the Devs Job), nor do they install servers manually (That’s the Ops job).

Don’t even get me started on “DevOps Tools” – Puppet, Chef, Ansible, Cloudify, Saltstack, OpsWorks, Jenkins.. these are all “DevOps Tools”, right? WRONG! They are automation tools! They don’t “DevOps”. They automate, i.e. enable “DevOps”. JIRA, HipChat, PagerDuty, CloudWatch, New Relic… these are communication, collaboration and monitoring tools. You get the idea.

There are no “DevOps Tools”. Developers have development tools because a developer is a profession. Just like a blacksmith has a mallet. Can you define a set of culture tools? Are the pen, the paintbrush, and the violin considered culture tools? No, they are instruments for the writer, painter, and musician to create works of cultural significance.

In the same way, there are automation, collaboration and communication tools that enable the DevOps culture to be implemented into the organizational DNA.

What we tend to mean when we say DevOps:
- ‘We use Puppet to manage our servers’ configuration’.
- ‘We use Ansible to deploy our application versions’.
- ‘We use AWS as our infrastructure’, ‘we use Cloudify for our orchestration.
What we should mean when we say DevOps:
- ‘Our Devs and Ops work closely together’.
- ‘They’re familiar with each other’s work so that Devs know the system they’re writing code for, (and adjust to it) and Ops know the code they’re deploying (and understand how it affects the system)’.
- ‘They develop in short iterations and can deploy fast (both infrastructure and application) to overcome bugs ASAP and create smaller problems if any new bugs arise’ (again, not mandatory, but can help).
- There are many more items in this list… but you get the gist.
This is enabled by:
- Keeping code tidy and well documented so it’s easily understood by all.
- Keeping our code under version control and backed up so that we can always go back to a previous version in our environments, when needed.
- Testing and monitoring the most important aspects of the system rather than the ones that we don’t care about.
- Automating our Infrastructure, because deploying servers and configuring them manually makes them more susceptible to human errors.
- Automating our code deployment so that we can deploy a lot (that doesn’t mean that we HAVE to deploy a lot), without making mistakes.
Where did we stray off course?

Culture is a very abstract and complicated concept. It isn’t as simple and obvious as a tool.

Along the way, we took the tools and skills that are required to implement DevOps and named them DevOps instead. We appended the skills necessary to deal with these tools to a list, created a job description, and from there… the rest is history.

What people refer to as “DevOps people” is usually (not always) a term that describes operations people who know how to code and who automate stuff – “InfraCoders”.

So pretty much, you can’t (well,you can – it just doesn’t make much sense) have a “DevOps Team” or a “DevOps Engineer” because “DevOps” is not a thing.

It is a how. It doesn’t respond to the question: ‘What’s your job?’ or ‘What does your team do?’ it responds to: ‘How does your company do it?’. And most importantly: DevOps, is “DevsWITHOps”, not “DevANDOp.”

Having said that, DevOps is not ONLY for Devs and Ops. It’s for everyone. It’s not about the titles or teams, it’s about the way a company handles the process of delivering a product to production in the best way possible.

The problem with the “everything is DevOps” attitude is that it renders definitions meaningless. If everything is DevOps, then it’s everything and nothing, and de facto has no meaning. DevOps is already a complex concept. Making it mean everything, will make it practically impossible to implement.

Ultimately, it really makes no difference whatsoever what you call your special forces team. You can call them “DevOps” or you can call them Bean Soup. Just be sure not to delude yourself that by constantly using the word DevOps in the wrong context, that your company is doing DevOps, while all you’re actually doing, is using Puppet.

About the Author

Nir Cohen – is an Ops Architect at GigaSpaces working on Cloudify and a co-organizer of DevOps Days Tel Aviv. He’s the brainchild behind the awesome open source tool Packman for package management. Nir loves system architecture, likes to think of himself as an innovative, think-tank type of guy who adores challenges and has an extremely strong affinity to automation and system architecture. He’s primarily driven by researching and deploying new systems and services. To Nir, the most important thing in life is ethics. Find Nir on GitHub or follow him on Twitter.
September 23, 2014
Lead from the Podium: 6 Essential Concepts New Technical Managers Miss
The transition from programmer to Team Lead or Software Manager can be a difficult one.

One week, you’re in your cubicle cranking out masterful code, and the next, you’re managing a whole team that has to navigate innovative solutions, coordinate input from different departments, then anticipate and eliminate potential showstoppers.

Stepping away from your identity as a superior coder into a role in management requires a whole new perspective on your work. Grasp the difference now, and you’ll save yourself months of frustration, friction, and fumbling.

Here’s the biggest realization that most new managers miss: you’re not a production unit anymore.

Starting now, you’re a leader. An encourager. A troubleshooter. A BS-caller. Most of all, you’re communication hub.

Your daily focus is no longer the perfection and elegance of your code, it’s the creation of something much larger using the coordinated work of many other people.

In other words, it’s all about communication and responsibility.

Think of it this way. When you attend a night at the symphony, you don’t go to see the conductor wave her arms around in an expressive and inspiring way. You expect to look past her the entire night, seeing only the orchestra as she keeps the whole group together, keeping time and leading the musicians through each crucial part of the piece.

She’s not making the music, but she makes the entire performance possible.

If the tuba player screws up–even in rehearsal–the last thing she’s going to do is march over, wrestle the tuba away from him and play the part herself. That’s just a formula for disaster.

Because the moment she forgets her role and steps off the podium to wade into the orchestra, the entire show starts to run off the rails.

It’s not the conductor’s job to play every instrument better than the musicians. They don’t need her to stand over their shoulder every moment in the practice room. And they don’t need a lecture insisting that there’s only one right way to play the piece.

Everyone, from the concertmaster to the triangle player, completely understands that they need her leadership at the podium to keep the entire ensemble together. They are relying on her to know the entire piece inside and out and have a good connection with each musician. This allows her to call out the best in them during the performance.

It is just as imperative that new technical managers stay at their podium. Most fancy leadership books are full of inspirational phrases, but they pass over this essential fact.

You and everyone else on your team needs to be secure in the knowledge that the while programmers are responsible for their craft and their individual output, you are in command of the entire process.

Even if your company hasn’t specifically communicated this to you, they’re very clear on your responsibilities for them. I’m here to help you understand those priorities–and own them.

Here are a few essential lead-from-the-podium concepts that every new tech manager should learn and develop.

6 Leadership Concepts Most New Technical Managers Miss
1. Keep your eye on the entire project. Yes, coding is your specialty, but unless you keep track of how every programmer’s output is coming together into the product, you’ll miss an issue that can derail yourself, your team, other departments and the delivery date.
2. Know the demands of the project and the players’ capabilities. This means reading between the lines of team comments like, “This is easy,” or “This can’t be done.” A solid manager knows what elements of the project are triggering these statements. He can also anticipate hidden complexity in a seemingly simple project or determine how he’s going to have to direct the team around hidden landmines.
3. Call BS on idealism and shortsightedness. Occasionally, a conductor has to be brave enough to hurt the tuba player’s feelings in order to have the entire performance come off well. Likewise, managers have to step in with a dose of reality when programmers insist that a project will “only take an hour”, and you have that gut feeling that even an all-night session won’t get it done. Remember that programmers are overly optimistic about their abilities, so build a realistic cushion into the timeline for them–and yourself.
4. Don’t take the tuba away from the tuba player. Just don’t. I know, you’re an expert at the work that you’re now managing. That makes it almost impossible to avoid the temptation to jump in and do it yourself. But let me tell you, this is the most time-sucking, team-killing mistake that most new tech managers make. It’s so destructive and prevalent that I’m dedicating an entire lesson to it soon. But for now, just trust me. Stick to your job and let the programmers stick to theirs.
5. Realize that communication–not production–is your priority. A manager’s value is crafting relationships on his team that allow him to motivate, direct, persuade, and correct the people on his team. This is the most important aspect of management and the core of your job. But after being in production mode for years, this kind of “work” can feel like you’re not “doing” anything. When you’re feeling this way, start tracking the number of conversations you have with your team members, and then see how your sense of your own production improves. Communication UPWARDS and OUTWARDS is just as important as INWARDS.
6. Take the blame when failure hits. While it’s natural to want to shift responsibility to someone else when the deadline was missed or a key function of the software bombed, but pulling the blame card just looks immature. Face the pain, learn the lessons and move on. Learn to say “My Team Screwed up” publicly, and then hold people accountable privately.
Making the shift from a respected programmer to an effective manager is a tough one, and not all of the best practices are obvious. The most essential realization you need to make–one that you’ll have to reinforce repeatedly in your first months in leadership–is that you’re no longer a maker.

You’re a conductor.

About the Author

Marcus Blankenship – Nearly 20 years ago I made the leap from senior-level hacker to full-on tech lead. Practically overnight I went from writing code to being in charge of actual human beings. Without training or guidance, I suddenly had to deliver entire products on time and under budget, hit huge company goals, and do it all with a smile on my face. I share what I’ve learned here.
September 17, 2014
Three essential elements to maximize business value with DevOps

DevOps is fast becoming the winning strategy needed to accelerate the continuous delivery of exceptional software without sacrificing quality and cost efficiency. With its focus on better communication, collaboration and feedback within and across development and IT operations, DevOps is gaining many fans – even in the business, where performance is seen as being directly attributable to its adoption.

I’d be the first to agree that buzz plus a liberal dash of hype follows any new tech trend. We’re seeing this big time with DevOps. Already it’s one of the most Googled tech trends.

Many vendors are washing and making ready their ‘DevOps products,’ while the #DevOps noise is shall we say, trending – we just love disruptive technology. If you have read the Puppet Labs 2014 State Of DevOps survey, organizationswith high performing DevOps teams were 2.5x more likely to exceed profitability, market share and productivity goals, and had 50 percent higher market capitalization growth over three years.

Don’t get me wrong I’m a disruptive tech fan too, but there’s a caveat – technology disruption is nothing unless it’s truly transformative– and that’s where I place DevOps. It’s not a technical nicety, but actually a business imperative for companies to thrive in an increasingly software-driven world.

Software applications are rewriting business. They’re no longer in the background ‘counting the beans’ and running the supply chains – they’re front and center – the mobile systems-of-engagement that shape your brand, delight your customers and, here’s really the cool part – disrupt markets.

Sounds great you might say, but there’s a problem– the traditional fixed speed limit on the super highway of business computing.

Enterprises have been stuck in the same gear for years maintaining large, complex/interconnected legacy systems. Mainly transactional and supporting complex business processes, the norm has been to change when only necessary (or forced to change?) – never exceeding the speed limit. Now however, consumerization of IT has dictated rapid delivery of software innovations. This requires a DevOps approach, where teams have a shared responsibility for not just keeping the lights on, but powering business.

Being able to increase pace is important, so too nimbleness. By making IT infrastructure more flexible and the instrument used to digitally engage and interact with customers, cloud drives business agility. But it’ll never realize its full potential if IT continues operating in silos using manual processes. This is why DevOps collaboration, shared processes and tools are so critical for harnessing the cloud – or using and an analogy – if cloud is the supercharged engine of business – DevOps is the fuel that powers it.

So with mobility and cloud computing being essential to a software-driven business, what additives do we need in our ‘DevOps fuel’ to spark agility and generate the greatest returns?

There are three big ones:

Agile Parallel Development

DevOps must reduce all elements of waste. This is a tough nugget to crack because existing IT environments generate tremendous inefficiencies. Often separate dev teams have to contend for physically constrained resources, with quality compromised by poor test data, shortcuts and bottlenecks. Testing especially is seen as IT’s “angry monkey”; something to be loathed, when in fact it should be a unified process that bakes excellence (functional and non-functional) into everything – from mobile apps and API’s to back-end systems – from dev day 1 and persisting right through to production.

With Agile Parallel Development and shifting testing earlier in the lifecycle, teams avoid delays in the development of high-quality code. Toolsets are important here, especially service virtualization, which by removing testing constraints reduces cycle-times plus prevents bugs finding their way into production. And, since business will increasingly engage customers across digitized multi-channels (mobile, API’s), teams will exploit real-time intelligence to test new ideas and experiments – pinpointing how functionality and performance converts to business gain.

Continuous Delivery

Release delays are a classic business fail. Now, success depends on delivering a continuous flow of value from new mobile apps, APIs and software innovations. These types of services will be constantly enriched to capture new markets and customers yes, but they’ll also be operating within shorter windows of business opportunity – faster lead times mean everything.

For IT, this ‘quick or dead’ imperative means teams must challenge a culture based on avoiding change and fear-of failure by using Continuous Delivery processes and tools to accelerate and streamline complex, multi-tier releases; automating the testing, deployment and promotion of changes across all environments. Additionally, these processes should integrate other management requirements – for example, establish service-level monitoring and reporting with the application when released.

Agile Operations

Agility must extend to operations. For too long we’ve been asking questions like – “how long can we go between failures?” or “who’s to blame for this problem service?,” but we should be asking – “If we want to increase customer conversion rates from our mobile app, what levels of performance are needed?” or “how can we detect and remediate performance problems before code reaches production?”

This shift requires Agile Operations – shared processes and tools that optimally manage applications, but also feedback intelligence to the extended team. For example, Application Performance Management should pinpoint operational problems faster, but also ‘gift’ development rich insights they can use to improve code quality. Furthermore, teams will leverage advanced analytics (like how, where and when mobile apps are being used) to drive just-in-time enhancements –that’s a new take on end-to-end– customer ‘engagement-to-experience.’

Business demand for software innovations is insatiable, and for good reason. Now the simplest mobile app experience or secure API can transform your business or screw it up completely.

By establishing a rampant innovation culture with DevOps and the right processes and tools, IT will not just meet expectations – it’ll be the spark for growth and innovation.

About the Author

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is on twitter @aruna13 and on Linked in

September 10, 2014
Transition to a new human ecology? We still need managers

Recently I replied to an article “DevOps Cuts Out The Middleman” that excoriated Middle Managers as a cancer. I commented that I disagreed. Nicely, I was invited to make further comment as the loyal opposition. I guess that makes me a sanctioned Troll. Hopefully I am informed enough to make a useful comment. FYI, I have developed software since the time of using x86 assembly gotoxy to move the cursor location on an amber screen. I consider MVC wonderful, but trivial. I have seen many, many projects, much good, much bad, some serious ugly and I have patiently watched like a Troll does. Worse than any Troll, I recently published a book on Philosophy, so asking me a question is generally contraindicated. Sew, you say Middle Mangers are an evil waste of time. May I politely disagree… and go down hill from there. The entire vision is deeply flawed and note they were described as “cancer”. How emotive. From strength comes weakness. From weakness comes strength. Know your weaknesses so they don’t bite you in the byte.

In a perfect world, no, we would have no use for Middle Mangers. The philosophy behind that critique of them was based on that. It is not a perfect world though and managers provide critical, useful leadership.

The description of a DevOps team in the article was the description of a machine. Why not? Machines are notoriously efficient and who is to argue with that? Except that we are humans and on deep levels trying to imitate a machine is something to be very cautious about. In the long run, it is a disaster. Machines are different. Machines are static, humans are not. Humans are far more random, so the system itself has built in risks. Face it, we’re developers and we are often best at imitating machines, which has its own liabilities, but we are not machines and even machines have problems. Human systems have problems sooner than machines, especially when acting like machines and trying to provide the performance of one. Managers are the repairman and lubricants of human based machines. They do the Configuration and Release Management for the team. They are the long term employees that know what is going on and how to handle the unexpected. Their job is providing continuity that only they can. They have the breadth of view that we lose at our keyboards. They smooth things over when a shock to the company comes like loss of a critical system or employee. Someone has to take responsibility. Who do you want it to be… Oh, stake holders. Yah right, they never did before they were called stake holders and still usually don’t. Another thing middle management can do (and I have seen this repeatedly) is when upper management makes a mistake (and they do), it is only the middle managers that can compensate. I won’t mention training and entry level, but obviously there is no consideration of that no matter how critical it is in the real world.

I will just refer to a Middle Manager as a manager, because in this day and age, you have management that are financial planners and you have management that produce a product, whether you call them managers, middle managers, project leaders or what not. That kind of manager provides many functions, hopefully. Think of it this way. Their importance is illustrated by the disaster that ensues when they fail. We all dread that. Leadership is a great skill and of great value.

The article assumed that everyone was proficient at their task. No, that is not the case. Skills and knowledge vary. I used the predecessor to .Net, the C++ Builder, but I am still learning C# now (await). Always a manager’s job is to get the job done with the resources they have. You may not have a team made of master developers. I have always appreciated a good manager, defined as one who gives me direction. A great manager is one that makes me more than I am. A good manager can make very good use of a weak employee and if the employee has the potential, a good manager can make them a strong strong, valuable asset. I know, Brian did that for me.

Developers are not known for our people skills. Those are the skills of a manager. Managers must be psychologists. Developers are smart and most know how to cooperate, but don’t tell me ego problems don’t arise. You can’t even get in the same room with some of the Prima Dona egos I have worked with. In any decent team, you likely have one Aspergers and likely a couple people with a problem dealing with it. Is it possible that anyone is immature? So, do you have someone who refuses to go to meetings? By the arguments of the article, meetings are very like Middle Managers. Then there are team members who need to catch the 4PM bus in Mumbai as well as the one who may not even speak English. Software development is like science. People think it isn’t personal, but it is. Someone has to manage the personal. Managers are a lubricant and without it, the gears of the machine are very likely to rub and grind. They can make a team succeed that could not operate without them.

A manager is a brain. Most team members are necessarily working on the details. Even the designer is swamped. The Scrum Master, besides being a Middle Manager anyway, has varying degrees of authority. An enforcer is needed. Someone has to tell people what the standards are … and enforce them. Someone has to decide how exceptions will be handled consistently. It provides its own efficiency. Chaos is never efficient. The manager provides the focus and order. That is their function. They must provide a focus that no one else on a team can provide. Systems help, but like there are no perfect laws, there are no perfect systems. Who enforces code reviews? Don’t tell me they just happen. I’ve been on great teams that were not under pressure and sorry, they were lax. How many times have I heard “we didn’t need to go down that rabbit hole”. A manager is like a judge that interjects the essential human element to a non-human system. A good project manager makes sure that the project is delivered. That is the preview of all team members, but just as we all have our special strengths, A good project manager will be the one that keeps the project focused and is going to deliver it come what may. We all know just how common a skill among developers it is to be able to interface with senior, non-technical management. Sure, anyone can do it or would you rather have someone with the skills.

OK, I’m a troll, so in respect for the thorough job I always do, it’s time for the mandatory ad homin attack. Lemme get to trashing the author of this article, Tony Bradly. Definite ignoramus. So he authored a few … well maybe a few dozen books. That means nothing! Decades of Security, Communications, Compliance and Systems Administrations leadership. Dum Dum Dum! Consults on systems for a bunch of Fortune … err … Fortune Rarefied companies. So what! Founded the Bradley Strategy Group. Anyone could do that. TV and Radio. A Celeb! Celebs always have opinions. So where does he get off thinking he needs to speak up? Actually, that’s not so funny. The guy is genius in a group of some of the brightest. Have you ever met anyone like him? I haven’t and I’ve worked on many teams and I remember a few truly incredible people, but not in that class. The article makes the assumption that the members of the team are all extremely competent, but that the manager is necessarily not. I don’t get it… or maybe I do. I reviewed the article to make sure I knew what it said. Odd, it said little. It did say middle managers were lazy, useless and a cancer. How very emotive. Ah yes, it looks like ideology. I recognise that flavor. That is a philosophy descended from Ayn Rand. I hear it is popular in Silicon Valley and much of IT culture. This is a model of a team of perfect individuals in a perfect world operating in a specific time frame. It is mostly illusionary, risky in the short run and self destructive in the long run by its static nature. The real flaw of the concept underlying the article is philosophically very deep. I know where this originates. Just remember the end of Ayn Rand’s story. They kept their ideological purity, but it resulted in the fall of darkness. This concept is based on a static illusion and like the story, there is no room for imperfection. I bet Tony has little need for managers or leadership, but he is one. Sorry, but most humans are imperfect and it works better to work with that than live an illusion that ends up fraught with danger.

About the author

Michael Breeden is a software engineer with over 15 years of demonstrated success providing a wide range of software solutions including the complete software application life cycle, relational database development, business objects and business support. He can be contacted at a1swdeveloper@yahoo.com or visit his website at http://a1swdeveloper.com/

August 21, 2014
Developing and enabling a DevOps culture in your team

We’ve all been there. You stare at an application that was built over the last four or five years. You look at the code, which is ugly, full of all sorts of workarounds and hacks built up over time, and you say to yourself, “If we just rewrite this from scratch, it will fix a whole bunch of edge cases and be easier to maintain.” But most of the time, starting over is the wrong approach.

That’s even more true when you look at creating a team to work in a more DevOps-y manner. People think of some platonic ideal of a DevOps team and say, “If we just hire people with these skills, everything will be perfect.” They look at the current state of affairs between developers and IT and say, “There’s no way we can get from here to DevOps with the people we have. Let’s start over.”

The people with the skills and experience you need to create a DevOps team are probably already in your organization. In our 2014 State of DevOps report, 57 percent of of our 9,200+ survey respondents said they were already using DevOps practices, compared with 16 percent who said they were part of a DevOps department. It’s pretty clear that you don’t have to be in a named DevOps department to be committed to using these practices. Since the term “DevOps” is pretty recent, but the practices are not, it’s also safe to assume that these named departments weren’t formed by a super class of engineers, but by people who were practicing DevOps before it was a thing.

Starting over is a clean-slate approach

People want to replace the team for the same reason that they want to replace all of their code: “Our application is warty.” All working code has bugs, workarounds and messy encounters with reality. Sure, some of your workarounds can disappear with a new design, but it’s not likely all of them will. Most of us feel a strong temptation from time to time to chuck it all, and start from scratch as if nothing were already in place — design and build a new, clean pristine system, and move forward from there.

Bringing in a new team to support DevOps is also a clean-slate approach, and it’s one that guarantees you will lose all the accumulated domain knowledge you have built up over the years: knowledge of the code base, of the business needs that drove development of this code base, and of how to work with others across the company. All this knowledge is not only valuable, it’s critical. A team of new people, whatever their technical skills, don’t have that knowledge, and can’t obtain it instantly.

The problems you’re facing are not all due to particular individuals on your teams; often, they originate in your organizational culture. That’s what you need to change. However the odds are good that you already have at least some of the people you need to create a functional DevOps environment. After all, your team has already had some successes, otherwise you wouldn’t still be in business, and it’s likely they’ve had to work collaboratively across the dev/ops divide to achieve these. Our 2014 State of DevOps survey showed that the longer a company has been using DevOps practices, the better its IT performance. It’s likely that you have individuals and teams succeed due to practices that fall under the DevOps umbrella, even if they weren’t using that term then.

Cultural changes (especially for management)

There are cultural changes involved in bringing DevOps to an organization, and sometimes these can seem insurmountable. These changes can be harder on management than they are on staff, because they represent values that are often quite different from how management teams traditionally work, or expect their teams to work. Taking a DevOps approach requires you to be comfortable with working in the open, with a much higher degree of transparency. Managers need to enable and support different kinds of information flow, across to peers instead of, or at least in addition to, the traditional flow of information from the top of the hierarchy down, and back up through the chain of command. Managers and technical leads also need to become much more comfortable with failure on their teams, viewing it as a sign of growth and a way to learn.

Start simple

How do you start building a DevOps culture? I recommend that you take a simple, easy-to-solve pain point and automate it away. Your existing staff are the ones who know what that pain point is, and you can’t automate a process without understanding what it’s meant to do.

Automating away one pain point will start the ball rolling, help staff feel more successful in their roles, and allow them to reclaim time to make further improvements. Done right, this is a self-sustaining process.

Create good interfaces between teams, and introduce reliable measurement so your team can improve day to day. That will help everyone feel greater trust in new tools and processes.

A window into what’s happening, and when

Get used to working transparently by putting in place a single and accessible ticketing system for tracking work and prioritizing it. The rest of the company should be able to see exactly what you’re doing, particularly the consumers of your services. People coming from a service desk background may have to adjust to providing more frequent updates and more details around issues, and for these updates to be visible to a much larger group than they are accustomed to.

Use your ticket system to drive buy-in across the organization. It will make prioritization of work highly visible. Anyone can go look at the ticketing system (however it is implemented), and say, “Ah, it looks like they planned to deliver this in the next two weeks but have pushed it out by a week due to an unexpected security issue.” The trust engendered by this visibility is critical when you’re trying to instill new values.

Across the silos

Get comfortable with horizontal connections in your company, with one team deciding that they need help from another, and asking for it directly. Don’t make information travel up and down a hierarchy — it’s a time-waster. Plus, remember the telephone game? The information that comes out the far end of the chain doesn’t bear much resemblance to what went in.

Encouraging people to work more laterally can be a really difficult change for a lot of managers. It doesn’t necessarily mean that they’re micromanagers; it just means they are used to information flowing up before it flows back down to another part of the organization.

Your DevOps efforts will probably fail unless your entire management team buys into the required changes, and executives recognize that they’re going to have to change the way they operate, as well.

A single source of truth

What makes large-scale system administration possible is automation and a single source of truth. That source of truth is the description of the desired state of the system.

The infrastructure-as-code movement really calls for a declarative approach: “This is the state a given machine should be in. It should have these services running, these packages installed, and configuration files that look like this.” Once you have a simple text-based description of that information, you can then check it into version control, you can create version tags, and you can cheaply maintain release discipline. At that point, you can actually start applying software engineering principles to managing infrastructure, another key DevOps principle.

What wakes you up at night?

We need to ask what causes manual work — especially work that ends up having to be done in the middle of the night — and how we can prevent it. What actually happens that makes us wake people at 3:00 AM to log onto a box and fix something? How do we prevent the change at its source? How do we test whether a given change will cause someone to be woken up at 3:00 AM to fix something?

For an operations team, these questions really matter. If you start thinking about everything framed by, “How will this behave at 3:00 AM? How will I understand what’s actually being changed?” and (better yet), “How can I stop my team from being woken up at all?” you have a pretty strong incentive to start writing effective tests.

Cultural barriers

The technical aspects of DevOps are not beyond anybody’s skills. It’s the cultural aspects that are going to make people uncomfortable up and down the line. The road to DevOps will be much smoother if you work at it incrementally to overcome these cultural discomforts, rather than throwing out all the institutional knowledge that you have, and bringing in people who are culturally comfortable with DevOps but know nothing about your business.

Just as DevOps is about incremental improvement of your infrastructure, you should be incrementally improving your people. It’s going to keep them happier, you’re going to make them more valuable employees, and it sends a really strong signal to the rest of the organization that you’re the kind of company that grows people according to organizational needs, and doesn’t just deal with change by hiring from the outside.

If you’d like to dive more into the data behind the suggestions in this article, or are looking for more concrete recommendations for managers and individual contributors, check out the 2014 State of DevOps Report

About the author

Nigel Kersten, CIO (@nigelkersten) came to Puppet Labs from Google HQ in Mountain View, where he was responsible for the design and implementation of one of the largest Puppet deployments in the world. He’s been a sysadmin for Linux and Mac deployments since before Mac OS became a UNIX, and was voted one of the 25 Most Influential People in the Mac Technical Community in 2006.

August 20, 2014
DevOps with purpose: It’s about your applications

This is Part 1 of a series on DevOps with a purpose by Matthew Selheimer, Chief Technical Evangelist and SVP of Marketing at Houston-based ITinvolve.

Unless you’ve been living under the proverbial rock these days you have no doubt heard about DevOps and the groundswell building around it. Today DevOps is being defined, promoted, touted and discussed as the next game changer in IT. Rather than argue about the best way to define DevOps in a general sense, this article will focus on something hopefully more useful – how do you determine what DevOps means for your organization?

A common goal cited for DevOps is to enable faster release and deployment cycles by taking advantage of agile development methodologies; improved collaboration between business stakeholders, application development and operations teams; and automation tools. Beyond these elements, DevOps also requires a cultural acceptance of the need to focus on the flow of work across teams vs. simply optimizing individual teams and their specific units of work.

By contrast, defining DevOps with a purpose means ensuring how you do DevOps is grounded in the realities of your specific organization. There is no “one-size-fits-all” DevOps, no matter what pundits, consultants, and vendors might tell you. Start by actually taking a step back. Ensure you are clearly taking into account your industry, your applications, your culture, and your people when developing your DevOps strategy; then apply DevOps principles against that foundation. Because every organization’s purpose will be different, your way of doing DevOps will not be the same as anyone else, even among your industry peers.

There are, however, some general guidelines you can start with and then apply them to your specific situation. For example, I recommend analyzing your business goals and application portfolio using the pace-layering method, which focuses on three categories of applications – systems of record, systems of differentiation, and systems of innovation.

Systems of record are usually quite stable with infrequent updates. This is often due to regulatory requirements and internal policies for theyse systems, and they tend to have a high degree of consistency within an industry and even across industries. Systems of record are often good candidates for waterfall development methodologies and longer release timelines. Your general ledger or payroll systems are good examples of systems of record.

Systems of differentiation are those applications that are likely common to your industry but where you have an opportunity to differentiate your company from the competition based on functionality and the pace with which you update them. For example, if you are a financial services firm that provides retirement investment programs, you might make changes to your customer portal and how clients select new investment options on a quarterly or monthly basis in order to enhance customer experience and remain competitive and differentiate. If you are an airline, this might be your crew scheduling application, which ensures you have the right flight crews available when needed and can improve your on-time departure percentages to differentiate from the competition. In healthcare, your systems of differentiation might be the applications that health professionals use to store patient information and correlate test results to aid in diagnosis and treatment. In manufacturing it may be your supply chain management, process control, or shop floor applications.

Systems of innovation are those truly groundbreaking applications that help you create new markets and revenue streams. In financial services, that might be a new kind of application that gives day traders a market advantage. For an airline that might be a whole new way of providing inflight entertainment, such as when Wifi and inflight entertainment first became available to passengers. In healthcare, it might be a new customer portal that promotes wellness services and reduces office co-pays by uploading fitness tracker data. For a retailer, it might be applications that support a new type of customer loyalty program, such as when Amazon introduced their Amazon Prime service a few years ago.

Both systems of differentiation and systems of innovation are excellent candidates for agile development and DevOps principles. This is because they require high degrees of collaboration between business stakeholders, developers, and operations personnel to ensure the applications are in line with requirements, developed and tested quickly, and then made available in the market to drive differentiation and innovation. They are excellent candidates for the continuous delivery concept in DevOps where small releases are deployed quickly (and can be rolled back just as quickly if there are issues). In this manner, a large number of small deployments moves the competitive needle faster and provides greater value to customers over traditional waterfall development and disconnected development and operations practices.

Defining DevOps with a purpose starts with an understanding of your industry and your applications. In the next article in this series, we’ll turn to the topic of organizational culture and its impact on DevOps transformation.

About the Author

Matthew Selheimer is Chief Technical Evangelist and SVP of Marketing at Houston-based ITinvolve. Reach him at matthew@itinvolve.com

August 7, 2014
8 tips on how to best manage distributed teams

More and more organizations are using distributed testing teams yet many are hard pressed to know how to manage teams that may be separated by thousands of miles away or on another continent. Too often, companies think about offshore product development only as a means to cutting costs and accelerating time to market. Such an approach can produce poor results with your projects if you don’t take into account certain issues like cultural barriers, metrics and workflows.

The smart strategy is to focus on the needs and skills of the team and to implement procedures that will help manage them better. Your standard bottom-line goals — cutting costs and accelerating time to market — will take care of themselves if you can follow these 8 tips for managing distributed teams.

1. Know Your Team

It’s important to address people correctly. People respond well when somebody knows how to spell and pronounce their name. To infuse a sense of team spirit, attach a face to the person who is communicating via email, phone or IM. Have a kick-off meeting for a project team, where each person introduces themselves with some basic personal information such as a hobby or interest, to help establish a ‘human-side’ to the offshore team. While meeting in person might not be a possibility, the liberal use of video conferencing can really improve the relationship with remote teams.

2. Eliminate Language Barriers

Working with remote teams on different continents/countries requires strong communication. It’s critical for the key contacts between teams to familiarize themselves with the pronunciation and grammatical styles of each other, while also ensuring that your team members obtains International English certifications, such as TOEFL. In addition, when possible, I recommend that the team leaders from the vendor side and client side visit each other’s offices to understand the culture of the companies and to instill a sense of partnership.

3. Clearly Define Roles and Responsibilities

To ensure that all members of the project team understand their expected tasks, it is vital to establish clear roles and corresponding responsibilities early on. Create a collaborative, pyramid-style team structure for the offshore team, so that the key people responsible for daily communication with the rest of the project team are identified, along with an obvious reporting hierarchy.

4. Create Strong Communications

The distance between remote teams working on the same project can be eliminated by use of communication tools such as IMs, VOIP-based phone calls, online meeting tools and other electronic mediums. However, communication is only as good as the information provided. All relevant documentation and domain knowledge must be continuously shared with all team members.

5. Track Detailed Onshore/Offshore Planning and Tasks

To ensure that your teams understand the assigned tasks and is progressing as expected, it is very important to have a milestone-driven WBS (Work Breakdown Structure) that identifies the effort associated with each task, and identifies the timeline of when the tasks need to be completed. This level of detail ensures that everyone is clear on their assignments, and that any delays (and corresponding affects) can be identified as early as possible, so that a mitigation plan can be implemented if need be. Team progress on assignments and activities should be followed up with daily, weekly and monthly reporting, leveraging defined templates where possible.

6. Establish Process Workflows

A clearly defined testing activity workflow should be established and reviewed with the offshore team, to ensure that all team activities are synchronized. Documenting a process workflow allows the team to streamline, validate and verify expected activities that could impact the project delivery timelines.

7. Don’t Forget Metrics

Offshore team deliverables and activities should be gauged with quantifiable metrics such as timeline delays, actual-to-estimated effort, QA-to-production defect ratios, and so on. Metrics should be established under at least three categories: timelines, productivity, and quality. These metrics should be established at the beginning of the project, and tracked either by release or on a monthly basis.

8. Establish Roadmap for Refinements

To ensure that the offshore team continues to increase its value to the project team, it is important to leverage the daily, weekly and monthly reports/metrics to identify areas of improvement/streamlining for testing processes and test strategies. These refinements should be prioritized and scheduled for implementation by the team, and tracked for progress along with other project deliverables.

In summary

Establishing and managing distributed teams is a complex challenge. Cultural differences, time zone variations and lack of face-to-face time contribute to the intricate nature of this model. In addition, some companies focus too much on cost-cutting objectives. To successfully manage distributed testing teams, a company needs to focus on people, processes and communications.

About the Author

David Keil is CEO of QASymphony, a leading provider of test management platforms for agile development teams. He previously served as CEO at Digistrive and at Integrated Broadband Services. He holds an MBA from The Wharton School and a BS in Applied Mathematics and Economics from Brown University.

August 1, 2014
IT Operations, Production Support and DevOps: 5 Tips for Remote Systems Tech Support

Cloud computing is a paradigm shift in how applications are delivered, developed, and managed. Because of this, Information that was available in the IT operations infrastructure may no longer accessible or available, putting the onus on architects, operation developer and DevOps teams to build capabilities into the application itself. Following these best practices can help establish a more efficient support process.

1) Application data must be accessible

Many of today’s cloud platforms, commercial frameworks, remote data centers and multi-services component based architecture are app-centric, and will not provide rich information or ongoing profiling access to the application infrastructure. Sometimes, there isn’t even any access to the file system or other server-side resources that are required for effective troubleshooting, and the limited access that the user does receive isn’t sufficient for forensics. That holds true whether you’re using a third party IaaS, PaaS, or install your application in a remote datacenter. Therefore, it’s critically important to collect as much descriptive application data available as possible. Agent or agentless (and sometimes both) approaches should be deployed to ensure that data is always readily available, and there are numerous solutions available for that purpose. Never rely on end users to supply your data for remote installations. Failure to include operational capabilities in the development environment results in long routines and processes that would make supporting each new application deployment or upgrade too inefficient to be sustainable.

2) Data should be in a readable format

Automating data collection and understanding events can be very challenging. It’s not uncommon for remote application data to be scattered across distributed environments in multiple formats and naming conventions (that’s especially true with dynamic environments, which typify cloud platforms). Your data should be organized to support a multi-tier infrastructure with a uniform format, design pattern, and structure. That will enable you to automatically access, add, and scan data. Keep files and data sources readable, accessible, and coherent; and stay organized: multiple Web servers can be logged to a common directory. Another helpful practice is to define tags in your application classes – it will make logs much more readable.

3) Log quality must be high

Gaining insights into remote systems is a one-shot deal: you won’t have other means to access data on remote systems. Gain as much understanding on the actual content and clean as much noise as possible from log files, up front. You will need as much detail as possible, quality patterns and formats, as well as rich descriptive and diagnostic data to traverse the cloud environment’s app-centric model.

4) Maintaining and reusing knowledge

Scientists share their findings through peer-review, which advances discoveries. Devops teams likewise can save considerable time and resources by understanding which messages and events other users already have already examined. Your applications will generate a massive volume of dynamic data, so maintain knowledge on what the data means and what has been learned from it in the past. It’s most helpful to perform analysis on your data – even when the log types, sources, and data patterns are all correct. Analytics helps devops support engineers and other stakeholders to understand whether a problem is preexisting or new. Reusing knowledge also helps to classify whether an issue is related to infrastructure, coding, or is another underlying cause, much more rapidly. Always keep some form of a runbook, whether it’s an automated commercial tool or homegrown.

5) Proactive troubleshooting

In today’s 24/7 app economy, it’s more important than ever to quickly address errors and anomalies before end users realize that there are problems. Try to anticipate the unexpected, and know when new releases or deployment happen – the problems may be coming from the remote infrastructure that you don’t support or have control over. Make appropriate use of application tagging and pre-fault analytics (application support shouldn’t only be post mortem). Above all, kill your darlings: manual processes no longer have a place in IT operations

Haim Koshchitzky is the Founder and CEO of XpoLog and has over 20 years of experience in complex technology development and software architecture. Prior to XpoLog, he spent several years as the tech lead for Mercury Interactive (acquired by HP) and other startups. He has a passion for data analytics and technology, and is also an avid marathon runner and Judo black belt.

July 29, 2014
The Continuous Delivery Pipeline — What it is and Why it’s so Important in Developing Software
Continuous Delivery (CD) is a software strategy that enables organizations to deliver new features to users as fast and efficiently as possible. The core idea of CD is to create a repeatable, reliable and incrementally improving process for taking software from concept to customer. The goal of Continuous Delivery is to enable a constant flow of changes into production via an automated software production line. The Continuous Delivery pipeline is what makes it all happen.

The pipeline breaks down the software delivery process into stages. Each stage is aimed at verifying the quality of new features from a different angle to validate the new functionality and prevent errors from affecting your users. The pipeline should provide feedback to the team and visibility into the flow of changes to everyone involved in delivering the new feature/s.

There is no such thing as The Standard Pipeline, but a typical CD pipeline will include the following stages: build automation and continuous integration; test automation; and deployment automation.
- Build automation and Continuous Integration
The pipeline starts by building the binaries to create the deliverables that will be passed to the subsequent stages. New features implemented by the developers are integrated into the central code base on a continuous basis, built and unit tested. This is the most direct feedback cycle that informs the development team about the health of their application code.
- Test Automation
Throughout this stage, the new version of an application is rigorously tested to ensure that it meets all desired system qualities. It is important that all relevant aspects — whether functionality, security, performance or compliance — are verified by the pipeline. The stage may involve different types of automated or (initially, at least) manual activities.
- Deployment Automation
A deployment is required every time the application is installed in an environment for testing, but the most critical moment for deployment automation is rollout time. Since the preceding stages have verified the overall quality of the system, this is a low-risk step. The deployment can be staged, with the new version being initially released to a subset of the production environment and monitored before being completely rolled out. The deployment is automated, allowing for the reliable delivery of new functionality to users within minutes, if needed.

Your Pipeline Needs Platform Provisioning and Configuration Management

The deployment pipeline is supported by platform provisioning and system configuration management, which allow teams to create, maintain and tear down complete environments automatically or at the push of a button.

Automated platform provisioning ensures that your candidate applications are deployed to, and tests carried out against, correctly configured and reproducible environments. It also facilitates horizontal scalability and allows the business to try out new products in a sandbox environment at any time.

Orchestrating it all: Release and Pipeline Orchestration

The multiple stages in a deployment pipeline involve different groups of people collaborating and supervising the release of the new version of your application. Release and pipeline orchestration provides a top-level view of the entire pipeline, allowing you to define and control the stages and gain insight into the overall software delivery process.

By carrying out value stream mappings on your releases, you can highlight any remaining inefficiencies and hot spots, and pinpoint opportunities to improve your pipeline.

Don’t Add New Functionality Until You Get The Quality Right!

Continuous Delivery is about enabling your organization to bring new features to production, one by one, quickly and reliably. That means that every individual feature needs to be tested prior to rollout, ensuring the feature meets the quality requirements of the overall system.

In a traditional environment, development teams typically try to implement an entire new version in one go, addressing software quality properties (such as robustness, extensibility, maintainability) only when the project is close to completion. However, as deadlines loom and budget pressures grow, quality is often the first thing that is compromised.

Poor system quality, low-user satisfaction and endless “quality band-aids” can be avoided by adopting the principle of not adding new functionality before getting the quality right. You should always first meet and maintain your quality levels and only then consider gradually adding functionality to the system.

With CD, each new feature is required to meet the level of quality expected for the system as a whole, right from the start. Only once this quality level has been reached can the feature be moved to production.

Getting Started With Continuous Delivery

Obviously, organizations cannot and should not rush into adopting Continuous Delivery all at once throughout all their business units. The best approach is to focus on improving your biggest delivery bottleneck. CD will automatically show you what the next bottleneck is. This puts you on a measurable improvement path.

The main goal of using Continuous Delivery is to roll out new features and functionalities that are better than previous iterations — gradually incorporating and refining the CD principle throughout the organization. Go slowly, go smoothly — and watch the improvements!

Much of the material here is covered more extensively in the book, “The IT Manager’s Guide to Continuous Delivery” which is available at go.xebialabs.com/IT-Managers-Guide-to-CD.html

About the Author

Andrew Phillips heads up product management at XebiaLabs. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.
July 29, 2014
In Support of DevOps: Kanban vs. Scrum
The Kanban software development methodology is getting a lot of attention as of late, particularly for its ability to enable DevOps. Some organizations are even going so far as to move from Scrum to Kanban to improve efficiencies. We use Scrum at OutSystems, since we’re doing feature development that requires stakeholder feedback. The sprint lock and end-of-sprint demos to stakeholders are invaluable to us. But I was curious to see how the two methodologies differ and how Kanban may further enable an organization’s move to DevOps. Here’s what I found.

There are two key differences between Scrum and Kanban: the rules and the workflow.

The Rules

Both software development methodologies provide rules for how work is performed. If your organization uses Scrum, then you know that it is quite prescriptive. Agile Advice lists 23 mandatory and 12 optional rules for implementing Scrum. These include, for example:
- A product owner creates and manages a product backlog
- Teams are cross functional
- Interruptions are prohibited during sprints
- Work is time boxed
- Scrum meetings are held daily
- A burn-down chart is used to measure progress
Taken together, these rules create a fairly rigid box in which teams must operate in order to be successful with Scrum. As I see it, this presents two big challenges. First, few organizations actually follow all of the rules, leading to what is called ScrumBut – We practice Scrum, but… ScrumBut means a company ignores specific Scrum rules for internal reasons, leading to a suboptimal use of the framework.

Second, at the core of Scrum is the time box. Time boxes are good for providing distraction-free time for developers to deliver the product, and define regular milestones for stakeholders to evaluate and steer the project. But, from a DevOps point of view, these artificial delivery checkpoints break the flow. Coordinating dependencies between sprints and ensuring their successful move to production becomes a big challenge.

Kanban, on the other hand, is less restrictive. Its rules are as follows:
- Visualize the workflow
- Limit work in progress
With only two rules, Kanban is an open and flexible methodology that can be easily adapted to any environment. (Some companies are using it across the entire organization – from manufacturing to marketing.) You can add rules as needed, borrowing from Scrum, if you so wish.

The focus on the flow instead of time boxes makes Kanban an attractive choice to use with DevOps. Deploying work items becomes just another step in the process, and with its emphasis on optimizing the whole delivery rather than just the development process, Kanban and DevOps seem like a match made in heaven. With the contrast in rules understood, let’s look at the workflow.

The Workflow

In addition to rules, the workflow differs in Kanban vs. Scrum. This is a direct consequence of the rule sets. In Scrum, you decide beforehand what features will be completed in the next sprint. The sprint is then locked, the work is done over the course of a couple weeks (the usual sprint duration), and the queue is empty at the end of the sprint. Locking the sprint ensures the team has the necessary time to work on a problem without being interrupted with other apparently “urgent” requirements, while the feedback sessions at the end of the sprints ensure stakeholders approve the delivered work and steer the project as the business changes.

In Kanban, you do not have the time constraints of a sprint, and the focus is on making sure the work keeps flowing with no known defects moving downstream. However, limits are placed on the size of the queues. This means that a maximum number of features or issues can be worked on at a given time, allowing the team to focus on delivering those work items with high quality. Making the flow visible creates a sense of urgency to keep things moving along. Note that Kanban was born in manufacturing, and its big focus is on productivity and efficiency. Kanban has to be extended in order to incorporate fundamental aspects of software success, such as stakeholder participation.

Enter DevOps

Organizations that adopt DevOps are looking to increase efficiencies, deploy features more frequently and be more responsive to business demands. You can see, then, how each methodology addresses various aspects of DevOps to greater and lesser degrees. Choosing one over the other isn’t cut and dried. Here’s what I advise:

If your team is responsible for feature development, which requires stakeholder feedback, and developers need to focus, Scrum is probably a better fit. The sprint lock and end-of-sprint demos to stakeholders can be invaluable.

If your team is responsible for maintenance and tends to be more reactive, then consider Kanban. There is no need to lock your backlog and you have more flexibility to respond to customer input.

Ultimately, every team is different. You know where your team excels and where it needs extra guidance. I suggest you borrow from both methodologies to give your team just what it needs to achieve DevOps’ goals.

About the Author

Rodrigo Coutinho is Principal Software Engineer, OutSystems. A member of the founder’s team at OutSystems, Rodrigo has a passion for web development, great products, and geeky stuff. He spends his time designing future versions of OutSystems Platform and dreaming about the cool future of the web.
July 29, 2014