Category: Trends

The Elephant in the room – 3 key points of DevOps – Strategy, Tactics and Implemention

Posted on | by ccadmin

Elephant in the room?

When people talk about DevOps, most people don’t know what their talking about or usually they only know part of what is DevOps. The blind men describing an elephant is what comes to mind.

One blind man says he feels it’s like a rope. The second blind man said it’s like a thick branch of a tree. The third blind man said it’s a huge wall.

DevOps is the elephant in the room.

We tend to only “see” one part of the elephant and we view it from our own role or perspective.

For many people, the answer of what is DevOps tends to falls between these kinds of viewpoints:

  • To systems administrators, it’s about use of Automation techniques to manage many machines and deploy code (i.e.Ansible, Kubernetics).
  • To a developer, it is a consistent code development environment and automated integration system (i.e. Docker, Git).
  • To a project manager and stakeholders, it is an Agile development methodology for software and product development.

These answers are both right and wrong at the same time. This is where the understanding of Strategy and Tactics come into play. With this, you can recognize and understand the “elephant in the room” and how to use these tactics and strategies.

The Difference between Strategy and Tactics

The culture and management practices of DevOps can be looked at as the Strategy. The implementation DevOps in the form of tools and processes used are the Tactics. One is at a global level, the other is the “hands on” task(s). Strategies don’t change often. Tactics do change depending on the situation. It’s an important to understand these perspectives to understand what “DevOps” really is.

What is Strategy from the DevOps point of view?

Strategy is the plan to archive a long term goal.  DevOps may employ many different strategies.  Here are a few examples:

These strategies are NOT always going to be appropriate for your shop for a variety of reasons and may need to be modified or other alternative strategies may need to be used.   SCRUM vs Lean?  Up to you and your team.

What is Tactics from the DevOps point of view?

Tactics is the actual methodology of implementation of a strategy.  Depending on your own needs and circumstances, the tactics you chose depend on the strategy your seeking to fulfill. Here are some examples of of tactics:

  • Using a Git shared repository is a tactic for Continuous Integration .
  • Using  Kanban software and workflow is a tactic for Lean software development.
  • Using Ansible to setup standardized servers is the tactic for the “cattle not pets” strategy.
  • Having small team of five people consisting of people from Operations, Development and Quality Assurance is the tactic  for the two pizza team and break down silos strategy.

Tactics may change for different systems you manage.  For instance an MDM (Mobile Device Manager) platform would be the appropriate choice for managing Smartphones NOT Ansible or Chef and in this sort of environment, Docker may not be appropriate for development of the front end app.

Implementation is the key

Even after understating the Strategies of DevOps and developing the Tactics to implement DevOps, if people are not DOING the tasks to implement the tactics,  just doing what they always done, they don’t have a DevOps shop. People need to participate. The place to begin is with collaboration and creating an environment where there is trust and the people involved are actually carrying out the tactics as day to day activities. To get collaboration, people need to have ownership in the project and get recognition for their part. Create an environment where people are willing to take risks and are not afraid of failure. To do this, it’s important that failure is valued as part of the learning process instead of blaming people or finger pointing.  In fact back in the 70’s at IBM, Tom Watson Jr. recounts calling to his office a young executive made a $10 million dollar mistake. Expecting to be fired, the executive presented his letter of resignation. Tom Watson just shook his head:“You are certainly not leaving after we just gave you a $10 million education.” Learning from failure is part of IBM s culture, it should be part of every successful company s culture.

There is NO right way to do this

You can read books like The Phoenix Project or  The Goal (Which The Phoenix Project is based on) and apply the Theory of constraints, or  read any number of books written about DevOps.    However, the original talk they done on 2009 10+ Deploys Per Day , Allspaw and Hammond didn’t do something all that new as these concepts were done by others.  Lean manufacturing is where Kanban and Lean software development came from.   Site Reliability Engineering , which is in principle DevOps, was developed at Google around 2003, well before the Velocity 9 conference.  At Netflix,  they weren’t thinking about DevOps when they developed their “DevOps” shop.
I am of the opinion that you have to examine BOTH the STRATEGIES AND TACTICS of what worked at various organizations and what didn’t and focus on collaboration.  Building a collaborative environment that encourages ownership of a project, gives recognition and encourages people to take risks and not be afraid of failure is the key first step to creating a DevOps shop.  Doing this will make adopting  the “Elephant in the room” less intimidating and will put DevOps in your grasp.

Feel free to give me your comments and suggestions.

Until then, have a great day.

Recommended Reading for DevOps – It’s Your Ship: Management Techniques from the Best Damn Ship in the Navy

Posted on | by ccadmin

So what would a book on management on a Navy ship have to do with DevOps?

Well it’s really a book on how Captain Michael Abrashoff created a collaborating organization on his ship while in the US Navy. As a result, he brought his ship from the bottom 3rd in the Pacific fleet to the best ship in the Navy. He increased his crew re-enlistment rate from 8% to close to 100% during his time on the USS Benfold.

The Military is know for it’s highly rigid command structure and for that matter its traditionally restrictive culture that discourages contribution and change. On top of that, you don’t get to choose your crew or your boss. Does that sound like a place you might be working for?

He created a collaborative culture by doing the following:

1 – See the ship through the eyes of the crew
2 – Communicating often
3 – Create discipline by focusing on purpose
4 – Listen aggressively

He also outlined how he did this in a restrictive military culture.
He would find ways to:

1 -Use dumb rules to his organizations advantage.
2 – Shelter his crew from the higher ups bad policies.
3 – Make his superiors look good and get latitude to run his ship.

Although this book has been out for a while (2002), these ideas presented in this book can give you some ideas on what you can do to implement the collaborative culture of DevOps in your organization.

Soft skills like communications and management are often overlooked by people in Software Development and Technical Operations. Take the time to improve these skills as it will not only enrich your workplace, but enrich your life.

If you have any suggestions or ideas, feel free to let me know.

Until then, have a good day.

Roy

Here is a link to the book:

It’s Your Ship: Management Techniques from the Best Damn Ship in the Navy by D Michael Abrashoff

 

DevOps vs Systems Administration – Why should I care?

Posted on | by ccadmin

Originally, I was going to write about Ansible and how to run it in a Windows environment using Vagrant, but as I started to write the article, I found that I had to describe how these tools were used and developed around the culture and philosophy of DevOps. Then, it occurred to me, I needed to describe what is DevOps. According to Wikipedia, DevOps is a software development methodology that combines software development (Dev) with information technology operations (Ops). Of course, I’ll use DevOps definition in a broader sense and more oriented towards operations.

Why should I care? Isn’t systems administration and DevOps the same?
Not exactly. Being brought up on old school Unix Systems Administration, I remember when machines consisted of dedicated hardware(CPU, Memory, Framebuffer, hard drive, etc.) software and network switches and routers. I would spend hours configuring individual machines using scripts or installing software (or compiling it) one machine at a time. I would be working with a team of people it seems firefighting. Keeping up with the demands of the users and their needs for additional resources…well was a pain. Then we turned the corner with virtualization where your machine is just a disk image sharing space on high powered hardware, more efficient, easier to use programming languages such as python & ruby (though this can be debated, but these languages are easier than programming c) and working towards automation. Mass on demand Virtualization is now called “cloud computing” or what I call Commoditized Virtualization. You can get VMs on demand and pay for what you need even by the hour. Out of these merging of technologies and software development methodologies (such as Agile) is where DevOps finds its origins.

Contrasting Systems Administration with DevOps.

Systems Administration tends to focus on being a tech…that is a power user who loads and configures software and plugs in hardware into the system. DevOps on the other hand focus on programming and automation of the system and network infrastructure. The mantra is “Infrastructure is Code” where you write and run code to make running the systems and network infrastructure more predictable and controlled.

System Administration tends to be reactive. That is you plug in the hardware/software and find out if it works and fix it as you go. DevOps is proactive in its approach. Use automation in a consistent and predictable way by using tools to test in a development environment before releasing it into a production environment.

System Administration tends to follow a “waterfall” approach to planning, getting requirements and deployment. You tend to make big expenditures of capital, time and resources up front. You fix it as the complaints come in. DevOps approach is more “agile” with many smaller changes to the system with plenty of user feedback BEFORE it’s all rolled out as well as DURING and AFTER the rollout.

While your company or organization may not be a software development house, i.e. you may be a web design company or your supporting your own companies internal network, you WILL benefit from adopting a DevOps approach as this can be applied to:

1 – Rolling out new software to your internal desktop users and keeping them current.
2 – Keeping your customers websites updated using automation tools.
3 – Being able to show management (and other stakeholders) what is accomplished and what is needed. You keep them in the loop.

While this is not ment to be an exhaustive treatise on DevOps, this should open your eyes to what is useful and what is possible.

In the meantime, have a good day.

Roy

Software is perishable – Identify your HIDDEN requirements.

Posted on | by ccadmin

Software is perishable

In a world where fresh food goes stale then rots, pets are born, grow old and then die, software is perishable. What do I mean by that?

Requirements change

Isn’t software something that once it’s written just does it’s task and doesn’t change? Yes, that is true, but the REQUIREMENTS needed to keep software useful will change over time. Often the changes can be swift and rapid. This can get you and your business into trouble if you don’t keep your eye on it.

A way to look at software is what reason did you get the software in the first place. It filled a need, a requirement.

For instance, I get an accounting package…lets say KwikyBooks. I get the package for my accounting needs. Well, what are my requirements?

1 – Generate invoices of my customers.
2 – Take payments and track this information.
3 – Generate various reports.

Hidden REQUIREMENTS

However, there are HIDDEN requirements that may not be obvious until you start using your software:

1 – What kind of hardware does this software run on. If you can’t obtain or afford the hardware, the software will be useless.

2 – Is the software secure? If you can’t keep your confidential business data safe, you will lose customers because they can’t trust you to keep the information safe. It’s just a matter of time before someone or something hacks your system.

3 – Is the software keeping up with industry standards and practices? Is it compliant with Federal, State and Local laws? E-commerce businesses, depending on it’s size, for example may have to track sales tax in EVERY STATE it sells to. Every year the Federal and Local government adds new laws and regulations that affect accounting and Tax laws. Having software that is non-compliant with industry standards and laws can cost you money and even your business.

In the same way, even though your software you have purchased or have developed for your company or customers may fulfill your original requirements, the HIDDEN requirements often will change because the software doesn’t change with time.

Prepare for Hidden Requirements

With this in mined, here is what I’d suggest you do when you either purchase software or have it developed:

1 – Check on the stability of the developer or company you are getting your software from. Even if it’s AWESOME software, if the software developers who wrote it go away, you can’t get the software HIDDEN requirements fixed. If your working with an independent software developer, I would recommend you use a well known open source framework  and languages. In the worst case scenario, you can find a python or java developer to take over development ant maintenance of your software than something written in let’s say a Esoteric programming language or a language that is not as common to use these days (i.e. Fortran, Pascal, Assembly, etc.)

2 – Get or obtain a service contract or maintenance agreement for the software. With this in place, you keep the software developer vested  to keep your software up to date.

3 – Periodically review your requirements and discover what your HIDDEN requirements are and get them addressed.by the developers. The HIDDEN requirements are usually found in changes in these three categories:

a – Industry rules and standards – Software is codified expertise that follows the rules and standards of your industry.
b – Laws (Federal, State and Local) – Legal requirements affecting your industry or profession.
c – Technology  – New technology and advancements, including updates and security fixes.

I would recommend you work with your software developer or software company to help you keep track of these areas that can affect your software requirements. Incorporate this process if you are working with Agile software developer.

In summary, please re-examine your software requirements regularly and make sure you keep you software fresh. Don’t allow your software to perish along with your business.

In the meantime, have a good day.

Roy

Distinguishing between new tech and tech marketing…

Posted on | by ccadmin | Leave a Comment on Distinguishing between new tech and tech marketing…

“Build it and he will come…”

That is a reference to the movie “Field of Dreams” where Kevin Costner’s character hears a voice that tells him to build a baseball field in the middle of his farm.  While the idea sounds crazy, you have to start building a project with nothing more than a prompting to get started.

This blog will be an exercise in just writing what I am doing in the technology world and to learn to be consistent in writing, more specifically, I will be sharing ideas for writing code, some projects I’m working on, new technology ideas and see what sticks.

Primarily, this blog will focus on front end development of hybrid mobile applications and desktop applications based on the JavaScript framework packages.  I will also delve into my thoughts of what’s useful or not.

Now with that said, there seems to be many different technologies that are starting to crawl out of the woodwork.  Some of the tech has the potential to solve some real problems, however other “solutions” are a form of “vaporware” which will be marketed widely, but when the marketing doesn’t take, will vanish like Silverlight or HDDVD.

It takes some time to learn a new framework or language and even more time to develop an application, so how do you avoid investing your time in a language or a framework  that is going nowhere?

I don’t claim to have a crystal ball or know the future, however if you are reading this blog, you do your research and get a couple of different perspectives.

Here are some of my thoughts:

1 – Be contrarian: if you see a product/service/tech that is heavily promoted in popular media, then be weary of it.

2 – Find out the value of the tool: Does it solve a problem that another (open source) solution already solve? Are there lower cost or free alternatives?

3 – Is it being used?: Are their other companies or groups using the products/solutions?

4 – What is the mind share of the tool?: How many people are using the tool for their project?

1 – Be contrarian.  One of the sure ways you can tell if you are in a financial bubble (over-inflated prices of a market) is when the news media such as TV, Newspaper, High volume news sites start saying about real estate, dot com stocks, Bitcoin, etc. saying that you need to get in before you lose out.  If this is true about financial bubbles, this is likely also true about hyping up new technology.  In this case, it would take the form of several technical books written about a new framework, Tech “Evangelists” who promote a given framework,  Free lunch seminars given by a mega marketing software giant.  You get the picture.

2 – Find out the value of the tool.  Microsoft Silverlight for example does have some nice bells and whistles that Adobe Flash doesn’t have, however with the new open source standards  that HTML5/CSS3/JavaScript was coming out with that you don’t have to pay licensing fees for and is ported to every platform, why use EITHER Flash or Silverlight when HTML/CSS/JS has the capabilities of both without the cost or other problems associated with proprietary solutions.

3 – Is it being used?: Do research on who is using a given platform or technology and what  solutions integrate into this.  AngularJS is used in many SPA (Single Page Application) websites and in addition is the core framework which Ionic (Mobile Hybrid Framework) uses for developing mobile applications.

4 – What is the market share of the tool.  Initially, when I was looking at a mobile cross platform framework, I was looking at Xamarin which appealed to me since I knew how to write code in C# and would not have to relearn a framework.  There was TONS of marketing in the search engines and books, speakers, etc.  This made me weary (see 1 – Be contrarian) so I looked up info related to the mind share Xamarin has and it represents about 2% of the market versus over 50% of cordova/phonegap.  This led me down the path of researching cordova, then Ionic.  Hybrid mobile apps are used everywhere both internally at companies and externally on Google Play and iTunes.

In either case, this is my though process on distinguishing between marketing hype of tech and what is actually will take hold and solve problems for you and your client.

If you have any ideas to share, please feel free to post or send me an email.

roy@customizedcode.us