devopsy.kinsta.cloud

Category: Doin’ DevOps

  • COBOL: Completely Obsolete But Omnipresent Language

    COBOL: Completely Obsolete But Omnipresent Language

    The programming language COBOL is a nuisance, something everyone wants to get rid of; however, I’m about to advise you to learn it. It might be a gold mine.

    The IT world is a fast paced one where obsolescence is the rule and where things evolve so fast that any person who wants to understand it has to continuously learn and train. Languages, methodologies and technologies keep on changing, evolving to make programming easier, safer more robust and above all, faster. As to every rule, there is one exception.

    In 1959, convinced that the English language would be more suitable for programming than machine code or the assembly language, Grace Hopper creates the first ever human-readable programming language that would survive for over fifty years: COBOL

    COBOL, 55 years old and still in its youth, not ever thinking about retirement, has become a nuisance, something everyone wants to get rid of but no one has the courage to try.

    Are we ready to replace COBOL?

    Nowadays, 80% of financial transactions are made through COBOL programs and most of those programs have been written decades ago and have proven to be reliable, effective and efficient. To top it all most companies which are still using it have invested a lot of money in those systems and if it is not broken, why fix it?

    So why would one want to change them? Well, it’s not Java. COBOL was created in an era where IT didn’t have the meaning it has today. A program was mainly designed to replace simple repetitive tasks such as retrieving data from a database, performing a couple of operations and generating a report or updating some other data. Today’s programs have to present a front-end to thousands of users, go through different layers of security, logic and quick data retrieving before accessing the back-end to ultimately alter data and send some information back to the user. Alternatively, a program can be a tool to design objects and buildings, communicate with your friends, frag your opponents, enhance your reality, you name it… The whole philosophy behind the conception of programs has changed so much in the last two decades that having such an outdated technology that almost no one knows anymore represents a potential danger. Only few people learn COBOL these days and even though those systems are not supposed to evolve much, there is always maintenance to be performed. But are we ready to replace it just yet?

    Fast, robust and future-proof language

    COBOL has been on the brink of death for years but its presence overall hasn’t changed. Not only are the cost to migrate from one technology to another huge but the choice of the replacing technology itself is a million dollars question. What better than COBOL to perform typical COBOL operations? While not designed to be an Object Oriented Language such as Java or C#, COBOL has slowly adopted some of their aspects, extending itself and its functionalities to a point where almost everything is possible. Everything with the exception maybe of creating user friendly or good looking Human-Machine Interface. In that matter, nothing has changed much since Hopper’s time. Many of us still remember the frustration of spending hours to get a simple screen with a couple modifiable fields and those who still use them must be dreaming every day to replace F5 and F6 by simple buttons…

    But that was never the point; the point was to have a fast, robust and future-proof language.

    COBOLs main contenders

    The discussion is still opened as to which language could replace COBOL but here are some pros and cons to the main contenders:

    –       Java is easy to learn, well spread and has a huge community of developers already but is rather slow compared to other languages despite the existence of some specialized compilers and massive improvements in the last few versions. It is also arguably still in its youth and the yearly evolutions and changes to the language don’t play in its favor. Not to mention the recent security issues.

    –       C++ is fast, flexible and robust but it takes time to learn and understand and has what is maybe its biggest flow, potential memory leaks. Something COBOL and Java programmers have, almost, never heard of. By conception, it offers a lot of freedom to developers but that also implies few ready-to-use components and thus it’s less cost-worthy.

    Let’s say that one day we manage to find a clear winner, another major problem will suddenly emerge. COBOL was made to perform all kind of operations in one block but we have learned throughout the years that modularity is the key to success. So if we replace COBOL itself by another language, we will also need to have databases and SQL, a front end and HTML, most likely a Business Process Management Software to externalize workflows… Basically, replacing COBOL programs means creating whole new ones.

    The ultimate piece of advice

    While it is possible to replace this aging language, this comes at such an extremely high cost that we can anticipate its presence in at least the next twenty years which brings us to the ultimate piece of advice of this paper: if you have the opportunity to learn it and enough motivation to write white on black interfaces, go for it. The pool of competent COBOL programmers is getting smaller by the day and the demand doesn’t change, meaning that this personal investment might reveal itself a gold mine.

  • A Culture of Trust

    A Culture of Trust

    Trust is by far the most critical element of a DevOps culture.  It is also the most difficult to achieve.  IT was not built for trust.  The silo structure that is common in most IT organizations was built for specialization and territorial ownership.  The silo walls are thick.

    While DevOps may not be able to break down the silos, but it can encourage and groom a culture of trust.

    Trust is difficult to define.  We know when we feel it, we know when we don’t.   In 1993, Dr. Duane C. Tway, Jr. published a dissertation called “A Construct of Trust”.  In it, Dr. Tway defines trust as

    “The state of readiness for unguarded interaction with someone or something.”

    Dr. Tway believes that trust is actually “constructed” from three basic elements:

    • The capacity for trusting
    • The perception of competence
    • The perception of intentions

    The capacity for trusting is how your total life experiences have developed your current capacity and willingness to risk trusting others.

    The perception of competence is your perception of your ability and the ability of others with whom you work to perform competently at whatever is needed in the current situation.

    The perception of intentions is your perception that the actions, words, direction, mission and decisions are motivated by mutually-serving rather than self-serving motives.

    While trust is individual, a culture of trust is organizational.   Both are earned.  DevOps is a great opportunity to look at Dr. Tway’s construct of trust and identify small but meaningful opportunities to steadily increase the trust between Dev and Ops including

    • Improved and honest communications
    • Increased personal interaction
    • Honored commitments
    • More listening than talking
    • Frequent knowledge sharing
    • Welcomed input and feedback
    • Admitted mistakes
    • Intolerance of blame
    • Mutual respect
    • A celebration of mutual achievements

    What else could you do to increase the capacity for trusting, perception of competence and perception of intentions in your organization?   Perhaps you can start with an honest dialog with and between your Dev and Ops teams.  The answers may be surprising and insightful.

  • It’s About What Works.

    It’s About What Works.

    Enterprises have been working through production delays and operational inefficiencies for decades. Don’t get sucked in too deeply to the ever-present mantra of “this time is different”. There is a lot of source material out there from people in a different kind of operations that have already been through the same wringer as DevOps presents. You just have to know where to look and remember in the end “it’s about what works.”

    SkyIsFalling

    I was talking to Lori about my concept for this blog, and she sent me a link to a pretty good (dated, but relevant in light of DevOps) PDF that introduces quite a few of the concepts. But let me pull from personal experience to try and show how little uniqueness is enshrouded in DevOps.

    Like DevOps… In the past.

    I was hired into a utility company a long time ago to take them from a run-of-the-mill utility to a fully implemented Automated Meter Reading utility. No utility in the country had gone to 100% automated for meter readings for a variety of reasons, some technological, some fear of change, some organizational. For the organizational part, imagine how many meter readers it takes to read 350,000 meters… Now imagine reorganizing without all or nearly all of those jobs. And imagine they type of jobs – automated meter reading operations and high-tech meter repair – that would replace them. It was a tall order.

    My role was strictly datacenter. I was given a mostly empty chunk of DC real estate, and told to build. When I walked in, there was a server for collecting the readings of the system that won the prototype phase, and some modems to read some meters that were already automated when the project was first conceived.

    While the engineering manager, operations manager, and myself overcame our various technological issues, others were dealing with the organizational issues. When I joined the company there were less than one percent of meters being read electronically. When I left the project two years later we were at 80% and the groundwork was laid to reach 100%. The organizational changes had been run through, both in terms of staffing issues, and in terms of resource utilization in IT. The transformation took a long time because physical hardware had to be installed on each meter.

    But reading errors rapidly became an exception. Cases where there was too much snow and the meter reader had to estimate? A thing of the past. Estimation was now reserved for exception cases, as normal operational procedure covered the vast majority of meter reads, even in blizzard conditions. And cost went down. While the initial investment was extremely large for a utility of that size, the ROI was solid, and rapidly that money was being recouped.

    What did they have to do? They had to conquer the three issues DevOps faces. Automate complex, error prone operations, make organizational changes that will serve the long term interests of operations, drive disparate groups to work together and understand issues impacting the overall project, and constantly monitor the ROI of the overall project.

    For that project, we were lucky in that there was more than buy-in from executive management, their was strategic priority. We got what we needed as long as we showed we were on track. DevOps is unlikely to achieve that level of support unless C-level execs can see the ROI and how it will help the organization going into the future. That’s the topic of my next blog, but luckily we won’t need that level of buy-in.

    …Is DevOps Today.

    Get a project manager, give them an operational process that is either done so frequently as to warrant special attention or is error prone enough to warrant special attention, and tell them to figure out the steps, who is involved when, and come up with a plan to automate it that can be achieved in a reasonable amount of time.

    Then set guidelines for what you will measure to prove success, and make certain you start measuring them in the current state if you aren’t already. Measurements are useless without a baseline.

    For an oft-repeated process, reduction in the time it takes to complete the process OR in the manhours required to complete the process is a good first measure. For error prone processes, measure rates of error.

    It is that easy to get started. While the PM will require some time of employees, if you choose the project well, the PM will be the only one devoting significant amounts of time to it… And you will come out the other end having a story to talk about. Hopefully having a success story, but even if the results are not enough to warrant further investigation, you’ll have a solid reason why.

    Are we increasingly hearing about nifty cool tools and whiz-bangs? Yes. And if you have the funds, go explore them. But always remember, first came DevOps, only then did tools get developed. Some will help you, none are strictly necessary, and DevOps rarely gets an overflowing budget.

    So hop on in there. You have done this a zillion times in each of the given areas of IT – how many standardized VM images or automated spin-up scripts do you have laying around for example? The only difference here is that you are doing it across more of IT, and you’re being more formal about it.

    And if the results of your first project show little improvement in your chosen measurements, you will have to look closely at the project, the PM, the organization, and the measurements. Each of these will lend itself to different solutions, it’s up to you to decide what to do for your company at that point.

    But likely, if you chose the project well, you’ll be off and running with little risk and much knowledge gained.

    And the PDF Lori sent me? It is about Business Process Management. And if you look closely at the steps, you will find that BPM was doing for the business pretty much exactly what we’re doing for ourselves now – reducing turnaround time, saving money, and improving customer (in our case the business user) experience.

  • Daddy DevOps

    Daddy DevOps

    2350073q9huagsinx

    I found out this week I’m going to become a Dad.

    It’s a strange mix of emotions from excited, to terrified, to panicked and happiness.

    Not too dissimilar to undertaking a big new project, scoping out how complex it is, getting close to go-live and then delivering it 🙂

    [if any one you say I should use Agile processes for childbirth go to the back of the class – having a baby is definitely Waterfall]

    At the moment I have time on my hands, which is probably one of the reasons I blog.  Time also gives you the room to think and ponder.  And because I spend all day, every day talking about DevOps I tend to think about it even in my downtime (and sleep) which is fairly plentiful despite a busy day job.

    With my partner away this weekend, bored of playing on the Xbox and all my friends busy/married/parents, I’ve done a fair bit of sitting around of late.

    I got around to thinking about how DevOps might compare to parenthood and I think there are some good analogies there.

    My goals of being a good Dad are:

    1. Ensure that the family is provided for
    2. Ensure the health of my child
    3. Ensure that the baby is happy
    4. Ensure my partner is happy and supported
    5. Ensure that the family are safe

    My partners goals are probably very similar so we shouldn’t have to worry about pulling in different directions too much.

    So that’s cool, we have 2 different parties (Mum and Dad) who’s goals and incentives are aligned and will work together to accomplish them.  The missus might not know it, but she’s soon to be living DevOps!

    I want to be a good Dad (and partner) and I’ve been thinking about what I can do as an individual to contribute towards our shared common goals?  And how do I make it easier for my partner to achieve her goals?

    Commonly, DevOps teams turn to automation in order to break down the silos between them and meet their common goals.

    If I could automate the changing of a nappy that would help!

    I’m not sure I can automate nappy changes (I’d be very rich if I could).  Does anyone know if Puppet have a Pampers module?

        
    nappy { '/baby/bottom/':
      ensure => clean,
      owner  => 'parents',
      type => 'huggies',
      source => 'crib',
    }

    Alright so I’m going a little off topic here.  My point being that we have two different resources who goals are the same (i.e. ensure the health and happiness of little Johnny).

    The stereotyped Dad in the 1920’s that went to work and had little to do with bringing up the child is a good example of a silo.

    I’ve gone to work, it’s your responsibility to look after the child – it’s not my problem

    Apart from the fact I want to be involved and I want to help my other half, I’m incentivised to help as much as possible because if I contribute then ultimately the happier we’ll all be.

    That’s DevOps.  Changing your behaviour in order to meet shared goals.

    Super excited.  Lets just hope the delivery isn’t Continuous.

    As ever, please feel free to take a look at my blog http://enterprisedevops.blogspot.co.uk/ or feel free to get in touch if you have any comments.

  • Me and My Kanban

    Me and My Kanban

    There has been a growing interest in the Kanban board, a tool that helps teams visualize their workflows, limit work in progress and get more “done”.   Kanban Boards are mostly associated with Agile Scrum teams as a collaborative means of seeing the burndown of a sprint.   In fact, Scrum and Kanban are considered to be so interdependent that a new framework called Scrumban is starting to emerge.   However, Kanban is not limited to Agile.  A Kanban board can be very useful for any project or scope of work that would benefit from visualization.

    The premise behind the Kanban is almost deceptively simple.  A board is built with three columns:  “To Do”, “In Progress” and “Done”.   At the start of each sprint, all of the work that needs to be completed is captured on individual sticky notes and placed in the “To Do” column.  When the task or work is actually being undertaken, the note moves into the “In Progress” column.  Upon completion, it is moved to the “Done” column.   If the team has successfully completed the work that was planned for a sprint, all of the cards that began in the “To Do” column will end in the “Done” column.  Any other result opens the opportunity for questions about impediments, team velocity (the ability to absorb work) and sprint planning.

    You will often see team kanban boards built on whiteboards and peppered with multi-colored sticky notes.  There is also a great online tool (www.leankit.com) that offers a virtual team Kanban board with many of the same characteristics.  If the three columns are too basic, you are able to add more columns because of the nature of the project.   My only caution is that it is easy to inadvertently make deceptively simple into overly complex.

    I have recently started to use a personal Kanban board to manage my own workload.  While not perfect, I have seen a significant improvement in my ability to get things done.   It keeps me organized and focused.   I like moving the sticky notes around.

    To begin, I created a backlog column with a colored note for each of my outstanding tasks.  The list is never-ending so notes are added to the backlog just about every day.  At the start of each week, I re-prioritize the backlog to ensure that deadlines and other considerations are addressed.  I then take a reasonable chunk of tasks off the top and add each note to the “To Do” column.  These are my goals for the week.  When I start to work on a particular task, I move its note into the “In Progress” column.  Upon completion, the note is moved to “Done”.   At the end of the week, I celebrate what I have accomplished and analyze what was left behind.

    If a note stays in the “In Progress” column for too long or moves back to “To Do”, I have to question why.  Did I overestimate my velocity or time it would take to complete a task?  Have I been faced with extensive interruptions or unplanned work?  Was I waiting on someone else?   The visualization of the Kanban board helps me understand my own patterns of work and recognize how I contribute to or impact the results of my team.

    I highly recommend that everyone set up a personal Kanban, whether for work or personal tasks.  It is a good opportunity to practice while enjoying the pleasure of getting more stuff done.    You can use the whiteboard in your office or set up a free basic online board (like me) through LeanKit  (www.leankit.com).   I assure you – the results will be very interesting.

  • It’s web performance, let’s not call it WebDevPerfOps

    It’s web performance, let’s not call it WebDevPerfOps

    Velocity was great this year. It was only my 2nd time out to Santa Clara, but from what I understand every Velocity conference is great. Few conferences can provide such rapid payback. Velocity does a good job setting the right vibe. The talks are often as entertaining as they are informative. This video of Scott Hanselman is a great example of that. He did an artful job of telling an open source audience they can run their code in the Azure cloud too. I happen to know a few companies that are doing just that. It’s good to see Microsoft continue to embrace open source, as I am a fan of running C# on Linux myself.

    Getting a room of passionate experts together and making them laugh over plenty of food and drinks is a setup for awesome collaboration. When this crowd is having a good time the conversation drifts to tech talk naturally. If you’re not working the hallway track at the conferences your attending you’re missing out. I always enjoy finding others dealing with problems similar to the ones I’m currently facing and the two way peer review that comes out of it. On occasion someone has a silver bullet too, where they killed a problem dead in their organization and the solution ends up being easy to implement and highly portable.

    As Velocity wrapped up I found myself with a 3:30pm flight back to Atlanta but a hotel with a strict 12pm checkout. I knew devOpsDays was coming up, google.io was going on, and a friend at the conference reminded me webperfdays was about to happen as well. Webperfdays was at Google’s Mountain View campus just up the street. When I looked into it the ticket was only $15.00, so why not spend half a day on Google’s campus talking about web performance if I didn’t have anywhere else to be?

    The session was awesome. Webperfdays was a much smaller group than at Velocity. The day included open spaces discussions in addition to main talks and an ignite session. I was learning so much I actually called at lunch to move to a red-eye back to Atlanta so I could stay for the full day.

    There were a couple of things that factored into staying after lunch. The first was I didn’t really know anyone there. I recognized a couple of people but it wasn’t anyone I had spoken with much. Looking at the line up for DevOpsDays, I didn’t see too many new names and had talked to most of the main presenters within the past couple of months.

    This was all enough to lure me in the door but I stayed because they blew my mind. Andrea Giammarchi’s talk on mobile web performance did real time demos showing how slowing your app can provide a more consistent experience across devices, but assuming only state of the art equipment can lead to performance problems for the majority of your audience. This blog post walks through the talk and provides links to benchmark tools used during the demonstrations.

    I also enjoyed Tony Parisi’s talk on webGL. In contrast, he made a lot of good points on how awesome our hardware can be and the crazy things it can do for us. This video covers a lot of the same points Tony made at webPerfDays. I was not aware of the 3D capacity our browsers have or how accessible it is.

    My mind sufficiently blown, I came to the realization I hadn’t really been thinking of web performance at all. I’ve been very focused on the CAMS model of devOps, which for the most part meant getting changes to production as safely and quickly as possible with lots of monitoring and reporting. The focus was really on not breaking anything. A degradation in performance does qualify a change as breaking if it’s severe, but making sure our numbers don’t slip isn’t the same as actively trying to make them better. This is a cultural perspective within a shop, and to promote that from within I have to become a web performance advocate myself.

    I don’t think I’m the only one guilty of adopting this devOps anti-pattern. It is human nature to pick teams and eventually get competitive. DevOps wants to de-silo our organizations, but I have witnessed industry experts self-segregate at the conferences where we’re working on correcting such problems. This is why I hadn’t really spoken with anyone at webPerfDays while at Velocity: We had all stuck to our respective tracks. The folks I knew were either at devOpsDays or had gone home.

    I didn’t have a lot of session overlap with the folks I work with because they were mostly on the web performance track. Since I’m a devOps Engineer it only seemed natural that we stuck to our areas of interest. I’ll even admit I’m guilty of actively turning off my attention on some deep dive performance discussions, because, “it’s not my area and I need to stay focused”.

    That thought process stopped as soon as I got back to Atlanta, and I hope you avoid viewing our industry so myopically as well. We have the capacity to study devOps, web performance, and more all at the same time. While we may not always be the experts in the room we can be fluent enough in other areas to be mindful of our impact and appreciate the wins and losses our teams face daily in their respective arenas. We can create a culture of sharing in our organizations, but if we can’t empathize with the information we’re receiving we cannot respond proportionally.

  • Network Engineers as Programmers? Not so fast.

    Network Engineers as Programmers? Not so fast.

    It is interesting, as the triplet new waves of hype evolve – cloud, SDN, and DevOps – that we are repeatedly hearing The Voice of Reason say things like “All network engineers need to be programmers”. While this is certainly not the only voice that demonstrates what I’m talking about, an example of it is Kirk Byers’ commentary on Network Computing’s site. (http://www.networkcomputing.com/data-centers/programming-an-essential-skill-for-network-engineers/a/d-id/1297898) I do not know Mr. Byers, and want to be clear, he’s not the only one portraying this wisdom, so the reference is merely that – a reference to the syndrome I discuss here.

    In DevOps, certainly having staff members that understand both application development and network engineering is a bonus. Being one of those fabled unicorns, I also know that they’re few and far between. I’ve worked with some great ones over the years that “just get it”, and they certainly add value to an automation project that involves networking. But there is a reason that there are few of us that understand both.

    I’m a programmer. I’m a very good programmer. In the course of my career, I’ve also become very good at strategy and even technical marketing. I learned networking because of my career path. When I chose to gear my career at new challenges, there were many. From datacenter administration to IT management, from storage and servers to networking to security, from cloud to embedded. I’ve enjoyed every aspect of my career, but I’m still ‘a software guy’ at heart… Just one that knows about networking, storage, and servers at a deep level.

    The thing is, my knowledge is not some magical formula. There are people in your enterprise that know all of this, and not all of them are software people.

    SquarePegI’m just suggesting we stop and think about it. When making the move to DevOps, there is a need for a certain set of skills. Those skills absolutely do not have to be vested in a single individual. There’s more overhead if you’re coordinating efforts, but think about what is going into place – automation scripts (of one form or another, no matter what tools you use) that have to have a big initial push to get developed, and then, unless your environment is in perpetual flux, just get used and occasionally modified.

    This does not require retraining of the entire networking staff. In fact, in maintenance mode, those scripts are not generally going to require regular work. Indeed, the largest changes to these scripts will occur as part of a pre-planned project that can take them into account.

    Looked at another way, developers sometimes need to deal with networking issues… Does that mean all application developers need to be retrained as network engineers?

    And there’s a risk. If you decide all of your network staff needs to learn how to code effectively in whatever language and/or tool you settle upon, some of them are likely to leave. Because they’re network engineers and not application developers for a reason. Just as I am at heart a developer, they consciously chose network engineering. For the amount of maintenance required after the initial push to get the automated portion of DevOps into place, one network engineer who is also interested in development is plenty. It doesn’t have to be the whole team. If it did, then all network engineers would need to be security engineers also, no?

    It’s a wave. It will wash over your IT shop in stages, cresting with the workload required to get the automation part of DevOps running, then receding, leaving ripples, but not a ton of water behind. Treat it as such. Get the help necessary to fill the gaps, put a team together that can address all the issues, then let them all go back to their roles, with added (and reduced) responsibilities that DevOps brings. Let developers do the development, working in tandem with network engineers. Find the network engineer that is most interested in development, and have them sit with the developers, working it out, getting everything right and learning what the scripts do. Then let that person handle maintenance, and let the developers roll back until the next major project needs teamwork.

    In the context of network engineering, system engineering, and application development, it’s a project, not a lifestyle change, to automate things. We know how to do projects, they don’t generally involve upheaval and retraining of entire teams.

    But if you’re still convinced you need the unicorn that can do it all, give me a call. That is, after all, what my firm does – bring knowledge both broad and deep to the table to help you solve problems – but honestly, most organizations don’t need someone like me nearly as much as they need a process, a list of attainable goals, buy-in from IT management for the manhour investment, and a plan.

  • DevOps the movement, or the function?

    DevOps the movement, or the function?

    All the ISVs and Enterprises are having the same question, who/what is DevOps. We get in a virtual room and talk about it, but we are often all scratching our heads at the same time. We are not confused from a technology or definition standpoint. There is so much chatter about this thing, it’s just hard to find the person or group that is doing it.

    My response to when I’m asked about DevOps is always the same. Are you are talking about DevOps the movement, or the function? The movement is what we are all hot and bothered about, but the function is where it really comes together and problems are solved. And even if you hate the movement, I guarantee your dev and operations team are inching in that direction, and some portion of the work already being done is in the DevOps spirit. (more…)

  • Now that you can consolidate, do not implode

    Now that you can consolidate, do not implode

    The development world is changing in a big way. We all know it. And it usually happens first with the early stage startups, who have the luxury of adopting new approaches from day one. One of those major shifts is consolidation of team members, where automation is taking over previous roles. In the modern development shop for example you are not just a front-end developer, you are a data scientist, a tester, a orchestration master, and a release manager. There are a lot of upsides to this consolidation, but a lot of downsides as well.

    (more…)

  • Change your thinking about Change Management

    Change your thinking about Change Management

    Change Management, let’s face it, it’s usually a checklist item and a CYA tool. But in the world of DevOps where change is part of the culture and processes.  Change Management needs to be more than a cost center, and really a way to improve what you are doing. And there is no excuse not to.

    (more…)