devopsy.kinsta.cloud

Category: Blogs

  • Containers Are Designed For an Antiquated Application Architecture

    Containers Are Designed For an Antiquated Application Architecture

    In his most recent GigaOm article, “We’re finally headed towards autonomous, self-migrating containers for cloud-application automation“, David Linthicum discusses the value that containers, such as Docker and CoreOS Rocket, are bringing to DevOps and cloud systems management. For the record nothing Dave states in the article is incorrect with regard to the expressed value that containers provide for portability, however, there is an issue with the big picture view discussed for the role of containers in cloud application delivery.

    Containers are predicated on the goal of deploying and managing n-tier application designs. By their nature, containers manage n-tier application components, e.g. database servers, application servers, web servers, etc., at the operating system level. Indeed, portability is inherent because all operating system and application configuration dependencies are packaged and delivered inside a container to any other operating system platform. Containers are…

     

    –THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

  • 7 Tips for testing the usability of mobile apps

    7 Tips for testing the usability of mobile apps

    Of the one million mobile apps, only half are used more than 5 times

    If you study any random cross-section of successful mobile apps and games you’ll find that they have one common factor. All of them are accessible. They have user interfaces that people can navigate intuitively without instruction. This is partly about building on expectations and established norms with Android, iOS, or whatever platform you are developing on. But there’s no substitute for thorough usability testing.

    According to Localytics, 20% of apps are used once and never opened again. Only 50% of apps are used more than five times. The window for app developers to impress and hook the user slams shut quickly and it stays shut. First impressions are vital if you want to boost retention rates and stand out in a crowd of over a million apps.

    It can be difficult and expensive to extract actionable data from usability tests. Here are a few practical tips for successful usability testing:

    1. Create a mock up – Starting with user-centric design is a smart move that will pay dividends down the line. You can save yourself a lot of time and money by discovering weaknesses and potential problems before the development really begins. There’s no reason you can’t mock up your user interface with simple screenshots and then frame it in an actual size smartphone surround. You can even do this with card and paper if need be. That way you can find out how potential users expect to interact with your app and identify the tasks that are most important to them. It’s a lot easier and cheaper to change your design on paper than it is to rewrite code.
    1. Examine how people interact – This applies to every usability test you conduct, whether it’s a paper mockup, a prototype, or the functional app on a smartphone. If you’re doing it in person then provide minimal guidance, ideally none at all, so you can uncover genuine failure points. Make sure to take plenty of notes. It’s not enough to just record what’s happening onscreen, you need to observe what people are doing with their hands, and see their facial expressions and body language. Are they trying the wrong gestures? Are they getting frustrated? Is it working the way they expect? Close observation will deliver the best insights.
    1. Test in the real world – If you can conduct tests in real world conditions in public then you might uncover some pertinent details about the usability of your app that you would miss in a controlled environment. This means conducting tests in real environments, whether it’s a busy shopping mall or a person’s home. It can be a good idea to avoid giving any instruction, that way you can see just how intuitive the design really is. There are services that offer video footage and audio narration of testers from around the world in different demographics using your app in real world conditions. Without the official framing of a test situation you have relaxed users and this can deliver different insights. Sometimes it might be more indicative of real world conditions to have someone test in their own home.
    1. Keep it short and simple – The longer a test is, or the more complicated it gets, the less likely it is your users will stay focused and interested. If they have to think too much about the parameters of the test and what you’re asking them to do then they’re less representative of an end user. This is particularly important when you’re asking members of the public to test in return for a small reward or for free. 
    1. Vary platforms and devices – Try to let people use their own devices wherever possible. That way the device won’t be a distraction and you’ll get data about different devices. The more variations you can cover, the more useful data you can gather. If you’re releasing on more than one platform then make sure you cover each one. You’ll need to cater for differences in expectations about standard platform navigation.
    1. Ask the right questions – Observation should be your primary source of data during usability tests, but you may want to ask some questions after each session. Be careful about what you ask and focus on getting actionable data. Asking if the app made them happy on a scale of one to ten isn’t going to tell you anything useful in a practical sense. You should also ask for elaboration, and where possible, have people show you what they mean using the app or prototype, rather than tell you, to avoid misconstruing any answers.
    1. Assess and act – You need to aggregate the data you collect and create a plan to assess it. Make sure you draw meaningful conclusions that are backed up by a weight of data. Don’t let personal bias cloud this process. You should be acting on the things that will resonate with the most end users. Just because one vociferous tester shouts louder than the others doesn’t make their feedback more important. Take your time, get further feedback on specific areas if it’s needed, and create a plan of action that you’re confident will result in concrete improvements, then test them again to confirm.

    There’s a lot of work involved in usability testing, but there’s no better way to improve the accessibility of your app and create a favorable first impression with the end user.

    About the Author

    Mush_Headshot cropMush Honda is QA Director at KMS Technology, a provider of IT services across the software development lifecycle with offices in Atlanta and Vietnam. He was previously a tester at Ernst & Young, Nexidia, Colibrium Partners and Connecture. KMS services include application management, testing, support, professional services and staff augmentation.

     

  • Bird’s Eye View of IT as a Service

    Bird’s Eye View of IT as a Service

    In working closely with large enterprises for several years, we consistently hear businesses talk of IT needs to achieve critical and strategic goals. Commonly these large enterprises span many verticals like technology, online media, finance, banking, and more.

    At the heart of their business goals, lie technology hurdles they need to overcome to scale as enterprises of the next decade.

    Visualizing IT as a service

    So we captured in this mind map high-level business goals that require a broad set of IT services ranging from infrastructure, applications, management, integration, service provider, and architecture.

    elasticbox-it-as-a-service-thumb

    If you look to the left, you see needs centered around applications. These detail all the services required to provision, deploy, and manage applications including application architecture models to design automated deployments and serve all the right infrastructure resources.

    On the right, you see needs that revolve around compliance, reporting, and integrating with various service providers to supply virtual infrastructure and a slew of related services to keep the infrastructure running smoothly and reliably.

    We find that this visual captures the entire IT-as-a-service industry as a whole and this exercise helps to understand where the customers’ needs are and where in that spectrum we assist them.

    See if you can pinpoint the areas where DevOps and IT Ops come into play.

    Enjoy the mind map and click to see a larger PDF view!

  • DevOps answers to high availability

    DevOps answers to high availability

    Everyone want’s their application SLA to be 99.99999%. However with some applications it is not a desire, it is mandatory. The Consequences of failure in mission critical applications are drastic. And with commercial applications damaging, it is reputation, and internal support costs.

    (more…)

  • Awkward questions for those getting started with automation

    Awkward questions for those getting started with automation

    This blog asking awkward questions for folks jumping on the microservices bandwagon was enlightening from the perspective that many of the same questions are applicable to operations as they begin to tackle operationalizing all the things in an application lifecycle.

    For example: “What is your deployable unit?”

    Great question, isn’t it? What is your deployable unit of automation? Is it per service? Per device? Per cluster of devices? Per container?

    Wait, but there’s more from this great list of awkward questions:

    • Is it acceptable for another team to take your code and spin up another instance of your microservice?
    • Can team A use team B’s microservice or are they only used within rather than between teams?
    • Do you have consumer contacts for your microservices or is it the consumer’s responsibility to keep up with the changes to your API?
    • Is each microservice a snowflake or are there common conventions?
    • How are these conventions enforced?
    • How are these conventions documented?
    • What’s involved in supporting these conventions?
    • Are there common libraries that help with supporting these conventions?

    All these questions are applicable to devops, in particular, as you go about building out automated scripts, systems and orchestrating processes that operationalize the data center and make it a lean, green deployment machine.

    You are going to have some kind of code, whether it’s a script or a recipe or a template of some kind, and questions regarding the usage of that code is important. Can others use it? Change it? Claim it as their own? Are they useful in a general, “here’s a basic load balancing provisioning and configuration script” or are they specific, as in “this is a piece of code that provisions and configures the networking required to ensure all 18 tiers of this very specific application can communicate”?

    And as you’re developing those scripts (that code) are you documenting it? Are there <gasp> comments? Do you use a standard convention for code formatting (cause let me tell you, where you place your brackets is a matter of great technical religious significance)?

    Most of those jumping into automation head first aren’t thinking of the long term ramifications of the choices they are making right now. Proof of concepts turn into pilots that turn into systems upon which all of IT relies. Rarely are you given the opportunity to go back and put any kind of standard conventions or practices into place. That’s what builds technical debt in software and, no matter what you think you’re building with those scripts, you’re building software.

    Adopting the technical and methodological practices of agile development is a good thing, but let’s not ignore that along the way from waterfall to agile developers have learned a lot of lessons the hard way. That means we should, as practitioners of software-related activities within operations (and that means any one of the four operations groups in IT), pay attention to those lessons and try to avoid the pitfalls that developers have already encountered and, one hopes, overcome.

    To do that, don’t just ask the awkward questions; answer them.

  • Commercial vendors gift to DevOps

    Commercial vendors gift to DevOps

    Open source solutions are usually brought to life because of someone’s yearning to solve a problem and share the solution with the rest of the world. Or perhaps when inventors are merely trying to get more eyes on the code for help with hidden bugs and fixes.

    (more…)

  • DevOps – what does “good” look like?

    DevOps – what does “good” look like?

    I’ve blogged a lot about my definition of DevOps and what it means to me.

    I’ve always thought it much larger than “Dev” and “Ops” and that there isn’t really an end state – it’s an ever changing idea that will adapt to meet the needs of the business.

    That said, I’m asked quite often what “good” looks like?  How do you know you are on the right path?

    For me DevOps is a primarily a cultural idea.  If the culture is right then the technology and people will follow.  I talk to a lot of people who see this word “DevOps” and reach out straight to technology.  DevOps isn’t another word for automating Cloud servers…

    In order to an effective “DevOps” organisation I think you need 4 main pillars:

    1. Culture – does the culture of your company promote collaboration, self improvement etc?
    2. Process – you need to have processes that support different silo’s working together to achieve a fast pace of change
    3. People – if you don’t have the right people then it doesn’t matter how great your technology is.  People and culture are very linked but I’ve tried to separate them here to demonstrate qualities that individuals hold vs values that the company holds
    4. Technology – what are the building blocks you need to be a mature DevOps enterprise?

    The following is very much my view of what “utopia” looks like.  The truth of the matter is that DevOps means different things to different people depending on what you are trying to achieve.  For example, you absolutely don’t need to use public Cloud to achieve DevOps.  However, I do think it’s a good pattern to promote working on high value tasks (rather than undifferentiated heavy lifting**) and using a common change process between development and Ops teams.

    This is where I want my company to get to…

    Culture

    • Measure everything, always
    • Individuals have empathy for the rest of the team (i.e. they don’t pass the buck)
    • Shared goals and incentives
    • Don’t reward the fire fighter, reward the fire preventer
    • Reward innovation and challenging the status quo
    • Don’t punish people when they try something new but fail
    • There is no IT and “business”.  IT as much “the business” as the sales people.
    • Seeking to break down silo’s
    • “It’s not my job” doesn’t exist
    • “Its my server/code/network/database” doesn’t exist
    • Individuals are empowered to make decisions
    • Top-up management rather than top-down

    People

    • Restlessnes (relentlessly looking to improve themselves, others, processes etc)
    • Good technical ability across a broad skill set (understand as much of other people’s jobs as possible)
    • Everyone can code and use version control
    • Everyone understands the test triangle
    • Dev-test pairing
    • Organised in small product focused teams rather than technology silo’s (align teams to the business not the technology)
    • Common incentive schemes
    • Favour automation and repeatability above anything else
    • CIO/CTO are DevOps biggest guardians & SME’s and seek to destroy anything that affects that  culture
    • Natural face-to-face influencers rather than endless emailers
    • Natural sharers of information
    • Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community)

    Process

    • Agile
    • Continuous Integration
    • Continuous Delivery
    • Lean
    • Fail-early, fail often
    • Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it)
    • All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production)
    • Knowledge sharing and “just enough” documentation is part of the process
    • Measuring success and failure is part of the process
    • Retrospectives are part of the process

    Technology

    • TDD/BDD everything (including Puppet etc)
    • Everything is in version control (code, automated tests, server config etc)
    • Release automation tooling
    • Convergent desired state tooling
    • Cloud (private or public but the ability to spin servers up on demand)
    • The same trending, monitoring & alerting solutions available through nonprod & prod
    • Application Performance Management
    • Service Virtualisation
    • Continuous Integration
    • Continuous Unit tests
    • Continuous Service level tests
    • Continuous GUI tests
    • Performance testing

    If you can get half way to delivering all of that then I think you should be in a very good place indeed.

    It’s a long hard journey if you are a traditional Enterprise.  Nothing worth achieving was ever easy though!

    I’m outta here for what proved a fantastically successful 2014 (personally and work).  2015 is a massive year too for me but good luck in whatever you have planned ahead.

    Happy New Year to you all!

    J
    xx

  • Top Skills for Enterprise DevOps

    Top Skills for Enterprise DevOps

    There is one question I hear almost every time I talk with my large enterprise customers about DevOps:

    1. What skills do my people need to be successful with DevOps?

    Talk of DevOps almost immediately focuses on culture – like having empathy for fellow workers, being flexible and adaptable, seeking continuous improvement, building relationships, etc. However, while critically important in DevOps, culture is an outcome, not an input; and such attributes are mostly either innate or acquired slowly. Culture cannot easily be taught.

    At the other end of the spectrum, we often look at technologies – agile development, coding languages, virtualization/cloud platforms, management tools, etc. Again, these can be important, but while learning these skills might make you a better dev or op, they may not make you a DevOps practitioner.

    Like most transformations, DevOps will need new people, process and technology skills, so in this post I take a look at a handful of the most important, pragmatic, and trainable skills in all three areas for practitioners looking to adopt DevOps, especially in large and more complex organizations.

    People Skills

    • Communication skills – while this may not come easily to typically introverted IT staff, both written and verbal communications, within and across the organization, and even with customers, are essential to a strong DevOps approach. This skill is learnable from formal courses, groups like Toastmasters, direct mentoring, social activities, or informal sessions like ‘lunch and learn.’ For extra credit, jump on stage for open mic night at a local comedy club!
    • Business alignment – much of a dev or ops life is spent embedded in the technology of software delivery, rather than the business need. This can cause many issues, and is something DevOps tries to address. Understanding the business strategy, goals and priorities is essential to DevOps, helps drive and easily trainable. A ‘big picture view’ helps everyone collaborate on common objectives to deliver high-value business outcomes – a key tenet of DevOps
    • Workplace history – “an appreciation for history, both technical and organizational”* will help staff understand the critical antecedents of DevOps, so they can internalize its principles not just rote learn its actions. For example, understanding hierarchical and network structures, why we adopted open work environments (and why it hasn’t always worked), and the antecedents of DevOps in things like The Toyota Way will help staff not just to act predictably in known circumstances, but adapt appropriately to new ones. (*Thanks to @garethr for input on this!)

    Process Skills

    • Agile development – it may be possible to take a DevOps approach in a waterfall environment, but it is almost definitely less effective. DevOps arose out of the Agile movement, and they pair so well that it is sometimes referred to as ‘agile for infrastructure.’ Teaching on one or more specific agile approaches (Scrum, Kanban, Kaizen, etc.) will give staff an approach and mindset informed by agile practices to help teams work together to improve flow, delivery and quality
    • Lean approaches – ‘lean’ theories born in the manufacturing world (see ‘history’ above) give a pragmatic foundation for applied DevOps, not just new-age ideals. Concepts like Just-In-Time, Toyota Production System, Design for Manufacture, Theories of Constraint and Waste can be learned from original texts, courseware and many business courses. Some are also revised in modern IT-specific texts like The Phoenix Project or Implementing Lean Software Development
    • Process reengineering – DevOps is as much about refining and improving ‘flow’ in the SDLC as it is about encouraging a sharing culture, so classic learning about how to effect change in business processes is invaluable to early stage DevOps adoption. Understanding how and why to analyze needs, identify problems, and effect change in software processes, organizational structures, teaming etc. is essential to DevOps and a long-established body of knowledge

    Technology Skills

    • Coding/scripting – in its current iteration there is a lot of focus on helping operators to understand coding languages; and teaching developers to use script-driven operations tools. From JavaScript (eek!) to C# or .NET, any coding or scripting skills will help both dev and ops to have empathy for each other’s jobs, and help to develop the elusive ‘T-shaped people’ that are so well-suited to a DevOps approach
    • IT Automation – Enterprise DevOps especially will likely involve (require?) a raft of technologies in an automated tool chain. Because DevOps is concerned with end-to-end flow, such skills need to cover the whole SDLC. Look to provide training in Portfolio Management, Agile Project Management, Source Code Management, Version Control, Test Automation, Test Data Management, Service Virtualization, Continuous Integration, Release Automation, Cloud Provisioning, Configuration Management, Process Automation, Performance Monitoring and Event Management, whether through formal training or informal knowledge transfer
    • Workflow mapping – smaller organizations might get away with pen and paper, or even a whiteboard/flipchart, but to document, share, analyze and rationalize the SDLC for large, complex, enterprise applications, you will need to learn to use workflow mapping tools. This will allow team members across the org (and the world) to take ownership of the end-to-end process, and start to collaborate on continual improvement

    This is of course a (very) short list, but should give you a starting point for developing essential skills for enterprise DevOps practitioners. As always, please feel free to drop a comment and tell me what I missed, what is more important, or even what I got wrong. I am always interested in discussing ideas and learning new things!

  • DevOps Resolutions For The New Year

    DevOps Resolutions For The New Year

    As we welcome in the New Year, it’s natural for us to set both personal and professional goals. While many are adding the obligatory eat healthier, spend more time with family, and exercise more to their personal list, some of our client are adding DevOps resolutions to their professional goals.

    During a recent customer roundtable discussion, we asked our clients what are their DevOps goals / resolutions for the New Year. Here are a few that stood out from the crowd.

    “Focus on fewer problem areas (bottlenecks)”
    -Ben S., VP, Major European Auto Manufacturer

    This is my favorite. It’s counterintuitive but makes perfect sense. With a topic like DevOps, it can feel over whelming at times. It’s for easy organizations to create a litany of things to do. Many enterprises hesitate to invest in DevOps not because they don’t know where to start, but rather they have too many choices on where to start.
    So this year, listen to Ben’s advice: pick the top 2- 3 areas that can make a positive impact to your organization. That may be continuous integration, or automated testing, or automated environment configuration. Whatever the area, just focus on a few areas, rally your team, and stick with it.
    If you are struggling with what to pick, use time, pain, and / or cost as your prioritization criteria. Even if you get it wrong, the impact on one part of your Software Delivery Lifecycle (SDLC) will highlight the bottlenecks in other areas.

    “Spend time talking to the people in trenches”
    -Jay S., Senior Director, Leading HealthCare Provider

    Jay hit the nail on the head. Too often we only focus on executive messaging and alignment. While that is important, talking to the people that are actually living this day in and day out is just as important. The insights you gain from them will be invaluable as you create your DevOps strategy and will go a long way when you try to get their buy in. Also, don’t just stick to the people within your silo. Talk to business, development, and operations – to get a holistic point of view
    If you are going to start a DevOps cultural revolution, you might as well get both top down and grass roots support. It’s the own way it is going to work.

    “Connect with others who have been there done that”
    -Ann H., VP, Major Telecommunications Company

    DevOps is a paradigm shift that challenges many of our long-held beliefs. It is a mind-set change and the only way to break the old way of thinking is to learn something new. So as the New Year unfolds, consider replicating Ann’s strategy: plan to connect with others who have been there and done that.
    We are at a stage in the market where many organizations have jumped in with both feet into DevOps. Some have been successful and continue to invest, and others not so much. Talk to both, you can learn a lot on what to do / not to do.

    “Stick To Your Guns”
    – John B., Snr. Director, Leading Technology Firm

    DevOps fails in an enterprise, not because of a flawed strategy, or mis matched tools, or even a bad process, but due to death by a thousand cuts. For example, breaking the continuous integration protocols and letting bad code pass through, increasing the batch size due to scope creep, not checking in code daily, and / or using non-standard pattern for deployment. Each cut, though small in nature, undermines the entire process. If done once in a while, it might be ok. But do it too often and you will literally see your DevOps investment vaporize into thin air.

    So if you were to add just one resolution to the list, I would recommend you follow John and add “sticking to their guns”. Whatever process that you and your team have decided on, stick to it. The more you stick to it, the easier and more natural it will become. Do it often enough and you will be setting the right tone for yourself, your team, and towards DevOps success.

    What are your resolutions for 2015?

    About the Author

    Mustafa-KapadiaMustafa Kapadia is Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. Through DevOps, organizations can get software to market faster, with better quality, less defects, reduced risk and shortened lead times.

    Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and and advisor to start ups.

    You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

  • Webinar: Managing CoreOS Container Performance for Production Workloads

    Webinar: Managing CoreOS Container Performance for Production Workloads

    As containers grow in importance, Linux distributions focused on container performance and management also are becoming mainstream. One of the most prevalent of these distributions is CoreOS. But how are real businesses using containers and CoreOS, and how are they monitoring container performance. After attending this webinar, you will have a better understanding of: * What is CoreOS and how does it work with containers * The trends in container usage and CoreOS * The key performance metrics you need to keep an eye on * How to manage performance as the container deployments grow This webinar will be led by Kelsey Hightower from CoreOS and Matt Williams from Datadog and they will leave plenty of time for all of your CoreOS, Containers, and Performance questions. By the end of the session, attendees will have a list of key performance metrics for containers on CoreOS they can start monitoring today.

     

    Video

    Slides

    [seoslides embed_id=”e307162e07b0″ script_src=”https://devopsy.kinsta.cloud/embed-script/coreos-datadog-slides/4095/” overview_src=”https://devopsy.kinsta.cloud/slides/coreos-datadog-slides/4095/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”coreos-datadog-slides” /]

     

     Date: Tuesday, January 27th, 2015

     Time: 2pm eastern standard time

    REGISTRATION LINK:(CLOSED) 

    About Speakers:

    kelseyHightower

    Kelsey Hightower is Developer Advocate at CoreOS.  has worn every hat possible throughout his career in tech and enjoys leadership roles focused on making things happen and shipping software. Kelsey is a strong open source advocate focused on building simple tools that make people smile. When he is not slinging Go code you can catch him giving technical workshops covering everything from Programming, System Administration, and his favorite Linux distro (CoreOS).

     

    mattWilliamsDatadogMatt Williams is the DevOps Evangelist at Datadog. This means he speaks, writes, and codes the technology to get everyone to believe in monitoring events and metrics using Datadog. In the past he has been the Evangelist at other startups including Placester and Yottaa, a Linux guy at Microsoft, and all sorts of other roles at Sun, Oracle, OpenText, and more. You can find Matt on Twitter at @Technovangelist.