Category: Features

  • Developing your organisation’s collective consciousness

    Developing your organisation’s collective consciousness

    Many organizations across the world are taking a long, hard look at DevOps and wondering how they can start to take advantage of its benefits.

    The 2014 State of DevOps report has some pretty compelling facts:

    • Companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals
    • They will have 50 percent higher market capitalization and growth than rival businesses

    DevOps might just be the key to organizational survival in the modern business environment.

    Sounds good!

    So, where do we start?

    Organizations  that want to start getting the benefits of DevOps need to recognize their implementation for what it is – organizational change. No, not hard-core bureaucratic change management with millions of forms to fill in, but an initiative that needs to win hearts and minds across the organizational.

    Remember – DevOps isn’t just an IT thing, and it isn’t just a business thing. It’s about collaboration, communication and integration right across our organizational.

    To be successful with any organizational change, there are a few simple things we need. We need a goal, we need a plan, and we need some enthusiasm. If we can’t get our people enthused and bring them with us, our goal and our plan will not have the momentum they need.

    One way to build enthusiasm and a common starting point is through education. It’s really important that every stakeholder understands the goal, the plan, and feels they have the tools, skills and level of empowerment to contribute.

    Getting staff the training they need can help build their capabilities and create a common understanding across the organization – a collective consciousness. DevOps is a simple concept, but some of the terminology that comes with it won’t be familiar to everyone. When you start to talk about continuous delivery and continuous deployment, you want to be sure that everyone is on the same page!

    DevOps implementations can learn from the way organizations have adopted other frameworks in the past. Common mistakes include a statement of management intent with no plan behind it – saying you’re doing DevOps doesn’t mean you are. Making sure your staff are all speaking a common language can really help to deliver success.

    The DevOps Foundation course from the DevOps Institute is a great way to start building that collective consciousness and get your staff involved in your DevOps initiative.

    The syllabus has been developed by leaders in the DevOps community and looks at where DevOps has come from, and covers topics including:

    • DevOps Culture
    • Organizational Considerations
    • DevOps Practices (the three ways)
    • DevOps and IT Service Management Processes
    • Automation Practices and Tool Categories

    Once your staff are trained, you can start to have a collective conversation about where you can make improvements in your organization, building on a common foundation.

    To get the most from your training, make sure staff know why they are attending the classroom course or taking the e-learning, and then have a plan to build on what they’ve learnt when they are finished.

    Read more about DevOps courses and find training providers here: http://devopsinstitute.com/doi-reps/

    About the Author/Claire Agutter

    Claire Headshot 3Claire Agutter is the lead trainer for ITSM Zone, global e-learning providers for IT management professionals. Claire has more than 15 years of IT management experience and loves anything that helps the business and IT work together to create value.
    ITSM Zone are the DevOps Institute’s exclusive e-learning partner.

  • Puppet Application Orchestration: Orchestrate the entire stack

    Puppet Application Orchestration: Orchestrate the entire stack

    In advance of next week’s PuppetConf, Puppet Labs is announcing a major new addition to their lineup, Puppet Application Orchestration. The orchestration functionality will allow users to automate configuration, deployment and management of your entire infrastructure stack, wherever it resides.  This is a significant uplift from managing just one instance or server at a time.

    I had a chance to speak with Luke Kanies, founder and CEO of Puppet Labs ahead of today’s announcement. Kanies has led Puppet through its 10+ year existence and has seen it grow from an open source project to over 400 employees, raise $87m in venture with over 1000 customers and more than $75m in revenue.

    I asked Luke what orchestration meant to him, as I think it is a term that is thrown around a lot in technology but not everyone agrees on exactly what it means. He gave me one of the best definitions I have heard, “orchestration is doing related things in a related way”.  In Kanies view the new functionality from Puppet Labs allows organizations of all sizes to “orchestrate their complete software stack allowing for the automation of the software supply chain.”

    This orchestration functionality is another step along the way of the eventual goal of a world where software is written primarily by software. This Matrix-like future Kanies believes is inevitable. It may happen in 20 years or maybe 50 years, but it will happen.

    The real key to this new orchestration tool is that it is more than just being able to automate multiple servers or instances. It actually orchestrates (there is that word again) how these disparate parts of your infrastructure run. It takes into accounts dependencies and events from other parts of the infrastructure in determining how and when to run other parts of it. Puppet says it best in their press release, “ensures that the right things happen in the right order on the right machines as the application is deployed, updated or destroyed.” This awareness is what makes this really special.

    Of course another big part of the equation is that this really does run across your entire stack. Whether it be in a public cloud, private cloud, hybrid cloud, bare metal, on prem or even containers, Puppet’s application orchestration can manage them all from one central app.  That is pretty impressive.

    To enable this functionality Puppet Lab’s team had to develop some new extensions and additions to its scripting language or DSL. This shouldn’t present much of a hurdle to the thousands of people who already use Puppet Labs products.

    Puppet’s new orchestration tool is another indication that the IT industry is becoming more and more app-centric. Applications are driving business and IT with it. Where they live and how they are built is complex and IT teams are looking for tools that make it simpler to deploy and manage these far flung, multi-homed applications that are popping up at ever increasing rates.

    Kanies himself will be demonstrating the orchestration module at PuppetConf next week during his keynote on Thursday, October 8, at 9 a.m. PT. If you are not attending PuppetConf you can follow along on the Livestream.

    It will be interesting to see how this new Puppet tool changes the market. It could set off another wave of integration and third party functionality that leverages this full stack management.  Who knows maybe somewhere right now there is some software writing some software that will take advantage of Puppet Application Orchestration.

  • Cloud Visibility: The Security Achilles Heel

    Cloud Visibility: The Security Achilles Heel

    As organizations accelerate their DevOps practices and move toward continuous delivery, cloud adoption plays a pivotal role. But visibility into cloud infrastructure and provider practices will remain a security Achilles heel until businesses can get better monitoring and insight into public cloud assets. According to a new survey out by the SANS Institute, even as the amount of sensitive data housed in public cloud infrastructure explodes, many organizations haven’t found a way to lick the visibility problem.

    Sponsored by CloudPassage and conducted among nearly 500 IT professionals, the survey showed that both PaaS and IaaS are on a huge upswing. In the next 12 months organizations report that they will approximately double usage of both models. IaaS in particular shows the biggest growth among cloud usage models, as 29 percent of organizations report they’ll deploy IaaS for the first time in the next year. Among the major drivers for this growth, 61 percent of organizations said time to deployment was key, while 54 percent said they were moving to the cloud because they can’t scale their own solutions.

    In those cloud deployments, well over half of organizations are processing or storing sensitive data in their public cloud environments or aren’t sure if they have sensitive data in the cloud. At least one in five organizations said they use the cloud to store or process intellectual property, customer financial information or health records. Meanwhile, 52 percent said they used the cloud to store and process business intelligence data, while 48 percent store or process employee records.

    Visibility concerns trump all others when organizations related their problems with cloud adoption—nearly 60 percent reported having issues with a lack of visibility into service provider operations. Nearly half of organizations related they had issues getting proper incident response support from providers due to visibility issues. And 46 percent reported having issues with VM and workload visibility. While not quite as widespread as general visibility woes, a quarter of organizations reported that provider-introduced vulnerabilities resulted in a breach or incident. Unfortunately, organizations are more likely than not unable to test for these kind of issues proactively. Only about 24 percent of organizations work with providers that allow them to do penetration testing on their public cloud assets.

    Diving deeper into this issue, one of the big problems is the inability for organizations to fold their cloud operations into overall security monitoring and management—37 percent of organizations reported there’s just a lack of consistent security controls that integrate with on-premises tools and security management.

    “The biggest issue, which goes back to the problem of visibility into internal cloud provider operations, is the lack of access to log files and other forensic artifacts, experienced by 53% of respondents,” says the report’s author, Dave Shackleford. He recommends that as organizations evaluate their public cloud relationships, they consider controls like logging, multifactor authentication, encryption and compatibility with security products that work natively within that cloud infrastructure.

  • The business benefits of DevOps

    The business benefits of DevOps

    As DevOps has become more of a mainstream concept it seems like there’s less need to define what it is or explain what it does. As prevalent as DevOps is for those of us who work in the world of DevOps or organizations that have already embraced DevOps there are still many businesses out there muddling along the old-fashioned way and wondering why they should care about DevOps.

    The simple answer is that not caring about DevOps may be suicidal. The 2014 State of DevOps report found that organizations successfully implementing DevOps tools and practices lead competitors in almost every relevant metric. Two statistics that stand out from that report are that companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals, and had 50 percent higher market capitalization and growth than rival businesses.

    Why is that, though? What is it about DevOps that leads an organization to be more profitable and productive? It’s a combination of three things, really: faster delivery times, greater stability / reliability, and freeing up time to focus on value.

    Let’s break those down some. DevOps is an evolution of the Agile development methodology. In fact, I’ve asserted in the past that DevOps is really just a matter of taking Agile principles and applying them to the rest of the company outside of software development. Whether Agile or DevOps the result when it comes to developing software is faster, more frequent delivery.

    Next we have greater stability and reliability. It might seem that the traditional linear method of developing software and releasing it on a pre-defined schedule is more stable. Developers and the rest of the organization have plenty of time to refine the code before it’s deployed, they know exactly when it will be deployed, and they know it basically won’t change for another year or so when the next major release is scheduled. The reality is the complete opposite in many cases.

    Developing with a rigid process methodology like waterfall means that only the changes and features identified at the beginning of the project are included in the release. As the need for improvements or additional features is identified during development those things are sidelined and added to a list to be pursued in the next release cycle. By the time the software is developed, tested, and deployed it is already out of date to some extent and bugs or issues that are identified take longer to address or get pushed to be handled in the next major release.

    The whole process is slow and results in less stability and reliability. DevOps yields greater stability and reliability because the faster development and more frequent release schedule enables organizations to identify and resolve issues immediately.

    Those two things combined mean that developers and others throughout the organization have more time available to focus on improvements and innovations that contribute to the bottom line. Organizations that have embraced DevOps also generally have tools in place to automate routine tasks which enables individuals to dedicate more time to growing the business and less time to pissing on fires and maintaining the status quo.

    DevOps has come a long way in just a few short years. There may still be companies out there trying to figure out why they need DevOps, but those companies won’t be around long. They’ll either figure it out and jump on the DevOps bandwagon or they will no longer exist to worry about it.

  • DevOps and legacy system lessons from dwarf planet Pluto

    DevOps and legacy system lessons from dwarf planet Pluto

    If you’re a bit of a space geek like me, then maybe you’re one of the 243 thousand plus followers of #NASANewHorizons; diligently monitoring deep space twitter sphere for the latest news and pictures from dwarf planet Pluto.

    The success of the New Horizons project is incredible – especially when you consider it’s all been delivered by legacy technology. Technology that lifted off back in 2006 – when Pluto was a real planet and before we had the iPhone, mobile apps, social media, Big Data, the Internet of Things, oh and DevOps.

    So why did this nine year old piano-sized hunk of tech deliver so impressively, and what lessons are there for those of us in IT managing our own legacy systems and applications? Actually there’s a lot we can learn from the outer reaches of our solar system.

    Even in Deep Space constraints can be managed

    The New Horizons space probe is an extreme example of a constrained physical system. Three billion miles from home, command sequences take 4.5 hours to reach the probe and the consequences of screwing as it barrels along at a lazy 30K mph are, well,  pretty severe. Of course NASA scientists have a fallback – they use a simulator with engineering and telemetry models to test the commands that perform all the vital spacecraft activities.

    In business computing we don’t have the luxury of having spare hardware of tap – especially for large legacy systems. Too often access to systems and data needed for development testing is constrained due to schedules, contention, security restrictions or service provider usage fees. To address this many organizations attempt costly provisioning of lab infrastructure, but these often don’t fully reflect production condition.

    As with New Horizons, constraints within IT can be eliminated with technologies that model and simulate the behavior of dependent systems. This not only lowers infrastructure costs, but also helps teams move testing activities earlier in the lifecycle, where in parallel with development help detect software defects well before they impact production systems.

    Change and release co-ordination is critical

    Just days out from its rendezvous with Pluto, New Horizons suffered a minor glitch and lost contact with the earth. For a $700 million probe at the edge of the solar system, that caused a few jitters. Then after a day of analysis (and maybe some head scratching), mission control tracked the problem to a timing flaw in the spacecraft command sequence. Basically, the main computer went into safe mode after being asked to do two intensive tasks at once.

    In enterprise tech our own legacy applications play an essential role in supporting key business processes. As such, and like New Horizons, changes must be carefully coordinated. What’s different, however, is the scale of the challenge. Multi-tier release deployments by nature are inherently complex with many dependencies. Automation therefore is critical, as are reusable and repeatable deployment processes to streamline application releases involving legacy systems.

    Data can be exposed and utilized in different ways

    It’s interesting to see how NASA have exploited social media for the New Horizons mission. Thanks to blogging, podcasts and Facebook all the news and fantastic images are now easily accessible. From the web-site too, the twitter API has been exploited to provide a constant channel of updates and facts about the legacy technology – did you know for example that the original PlayStation CPU (MIPS R3000) is used in the probe? – I guess if it worked solidly for a 100 million game units it can fire some thrusters 3.5 million miles out in space.

    Businesses operating in an economy governed by software applications can take a lesson from the New Horizons mission. Application Programming Interfaces (APIs) are now central to the exchange of value between companies, so it makes complete sense to use them against legacy systems and line of business applications.  By securely unlocking the application data (and business processes) through API’s and by seamlessly managing message mediation and translation, organizations can have these older systems quickly participate in more modern processing and customer-centric computing.

    Every system is a legacy system

    Just as we rush to embrace every shiny new tech object, we can be equally hasty berating the value of existing systems and applications. To this end, legacy becomes a term of derision; associated with everything bad about enterprise computing. The more pragmatic among us know this isn’t so. After all these systems support a plethora of back-end business processes and continue to be the transactional work-horses upon which many businesses depends.

    There’s a lot we can learn from the New Horizons mission. Even now scientists are saying that the spacecraft has decade’s worth of exploration left in it. So with some quick course adjustments it’s off to explore the next icy world.

    Not bad for old space tech – perhaps in business computing we should be thinking the same way – extracting value before prematurely consigning our own legacies to application scrap-heap.

  • DevOpsSec – Creating the Full Triangle

    DevOpsSec – Creating the Full Triangle

    Introduction

    As a discipline, DevOps emphasizes uniting development and IT operations teams through modernized culture, integrated tooling and processes in order to increase the frequency, quality and business alignment of software roll-outs. But while developers and IT Ops teams need to be in lockstep, security cannot be an afterthought.  Rather, DevOps teams need to adapt to include security as an integral part of the agile triangle.

    The challenge facing DevOps teams today however is that incorporating security into their day-to-day work is not always easy or intuitive. Security often runs one step behind or out of sync with lean DevOps teams. In addition, the besieged security professional or team often faces a never-ending barrage of breaches, designed by a large, amorphous and highly motivated hacker ecosystem and resulting in a continually escalating threat environment. In an effort to save time, agile developers may leverage existing code in rapid iterations and quickly deploy them to production through continuous delivery pipelines, without considering existing architectural defects or knowing its defect profile and potential for security vulnerabilities. This can expose organizations to huge risks if left unassessed and mitigated.

    Fortunately, “security at the speed of agile” is entirely possible, allowing organizations to bring new software products and services to the market, while staying in control. Here are some best practices for better aligning security with DevOps objectives, evolving beyond just DevOps to DevOpsSec:

    Shifting security “left” in the DevOps chain

    Like functional quality testing (making sure an application works as it’s supposed to), security testing needs to happen in the earliest possible stages of the development process. Traditionally, the application lifecycle has followed a sequential model – ideation, development, testing and finally, production. Functional testing used to occur only during the testing phase. But now, developers are taking on more responsibility, which helps prevent defective code from getting “baked in” further down the application lifecycle, where it becomes much more time-consuming and costly to undo. However, security is also an extremely important part of the quality equation, and if a security defect isn’t detected early on, a very unpleasant surprise is likely in store as the application gets closer to production. Building in and continuously integrating static code analysis and dynamic security testing into the Agile application lifecycle is a key success factor to delivering a high quality, secure application experience in production.

    Automating security testing, for both developers and testers

    In agile environments, DevOps teams are under constant time pressures. As noted above, developers are expected to develop more and more code, all while assuming greater responsibility for functional quality. Testers, too, are under increased pressure as more frequent application roll-outs mean more testing, in less time. For these reasons, if security testing is going to take place earlier on in the application lifecycle, basic security tests need to be automated. Since security threats are constantly evolving, this kind of automation will not completely rule out all security flaws in production. But it will allow developers and testers to spend more time on their core functions – namely development and functional testing – while lowering the attack surface, once an application does reach production.

    Leveraging Big Data analytics 

    Data generated from DevOps processes and operations, particularly related to automated security tests, often hold a wealth of insights which can be used to step up security validation efforts throughout the application development lifecycle. For example, what code types show the most vulnerabilities and therefore may need more rigorous testing? Which groups of developers are discovering the most security holes in automated tests – such that their development processes may need to be refined — and which groups may not be testing enough? How long are basic security tests taking on average, and how does this need to be factored into roll-out timelines? This type of data can help DevOps teams prioritize and optimize their security testing, and better reconcile security testing requirements with velocity and resources to hit anticipated delivery dates. Also, while using Big Data analytics in production will always be useful (particularly when it comes to detecting new security threats, and determining new automated testing needs), applying Big Data analytics earlier on, to DevOps pre-production data, can prevent more security flaws from making it into production in the first place.

    Fostering a shared vision and objectives

    To date, real progress has been made uniting developers and IT operations teams together in DevOps organizations. Traditional roles and responsibilities within DevOps teams continue to evolve and coalesce, and that’s a good thing. Developers are contributing to testing and taking more responsibility for overall quality. IT ops teams are thinking like developers, analyzing and feeding production data back to developers and testers so they can fine-tune and modify their offerings. Data flows left-to-right, and right-to-left are becoming more automatic and continuous.

    But increasingly, security professionals need to be included in this mix. Developers need to think with security considerations in mind – for instance, will a new feature they want to add to an application bring increased security risk, and if so, how can this risk be minimized? Conversely, security professionals need to think like IT ops teams; for example, making sure a new mobile app doesn’t potentially create a hole for hackers to penetrate back-end systems, and if a hack were to happen, how to contain it and minimize the impact. Only by capturing the right data, communicating and committing to working together can everyone in the DevOpsSec chain make the best, most well-rounded decisions that factor in all concerns, with business success being the top priority.

    Conclusion

    Often, DevOps teams may view security teams as potential logjams preventing them from doing what they want to do – deliver working software quickly to delight users and create competitive edge. But if security in the software supply chain is not addressed, the results may do the exact opposite, frustrating users, freezing business processes or worse, causing massive financial liability and loss of brand goodwill.

    Security is a key ingredient of application quality. By addressing security earlier in the development process; increasing security testing automation; leveraging Big Data analytics and incorporating security in the DevOps mission, organizations can achieve true DevOpsSec and deliver applications that are high-quality, through and through.

    About the Author/ Kelly Emo

    Kelly-Emo- Director-Lifecycle-and-Quality-HP.jpgProduct MarketingKelly Emo, Director, Lifecycle and Quality Product Marketing, HP, Kelly has been involved in all things IT for few decades, including engineering, product management, and product marketing across application development, SOA and middleware, enterprise architecture, IT operations, quality and testing. She now focuses on application lifecycle management, quality, agile development and DevOps. She has worked in other organizations at HP, BEA Software, and Jamcracker Inc .Kelly has a BS in Computer Science from Cal Poly, San Luis Obispo and an MBA from Santa Clara University.
  • 4 big challenges of microservices

    4 big challenges of microservices

    The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.

    First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.

    Al Hilwa, research director, Application Development Software at IDC described microservices this way:

    “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

    Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.

    Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.

    1. Insufficient guidance

    When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.

    2. Getting it wrong

    There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.

    3. No going back

    You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.

    4. Deliver value

    Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.

    Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.

  • The Scalable Path to DevOps Career Training & Development – A Premium Talent Marketplace

    The Scalable Path to DevOps Career Training & Development – A Premium Talent Marketplace

    “Our company is a premium talent marketplace with on-demand leadership and clients mostly in the Bay Area, Silicon Valley, New York, and other metropolitan areas,” says Tomas Gutierrez, Partner, Scalable Path, a geographically-distributed network of more than a thousand software architects and developers. Scalable Path serves clients such as tech startups and product companies by helping them build software teams and fill technological gaps. Given that Scalable Path assists with software design, its clients most certainly have needs in DevOps approaches. Scalable Path’s Gutierrez informs devopsy.kinsta.cloud about DevOps career training and development priorities and building blocks.

    Foundational Knowledge

    At Scalable Path, a good working knowledge of the seven layers of the Open Systems Interconnect model is important for software engineers who want to work with DevOps approaches. “In order to have a full mental picture of what is happening where, software engineers must have a conversational knowledge across all these layers,” says Gutierrez.

    With any application of software, you will host it on hardware, you will have an OS, and hosts will talk to each other across a network. “The DevOps engineer must know the seven layers involved in order to consider goals for infrastructure as code and to help with software releases, deployment of infrastructure, networking, and configurations,” explains Gutierrez.

    Applicable Traits

    On the job, a good DevOps engineer must be a good problem solver, be able to think outside the box, and have empathy for the needs of the software product and the organization, says Gutierrez. Attention to detail and a security focus are also worth accounting for.

    “Even though it’s good to have formal training, college degrees, and certifications, the right personality, that of an autodidact (one who is self-taught) is key for good DevOps talent,” says Gutierrez. These engineers will examine a technical challenge globally and in its component parts and seek and assemble the tools and processes that will provide a complete solution.

    Further, someone who is empathetic to the needs of the software and the enterprise deploying it will realize when they need to use a simple, cost-effective software deployment without all the extras.

    The ability to direct a focused attention to the details of software engineering is another important trait for a DevOps engineer. Otherwise, programming errors occur that can create issues down the road. “If you don’t architect something correctly, you may end up with part of your architecture failing because you made some mistake in programming,” says Gutierrez. These things can propagate and scale up into bigger issues as the architecture grows.

    It’s also important for the DevOps engineer to be strong in security such that their programming does not expose critical data. It’s about how the programmer constructs the data layer, how they work with the transport layer, and what the end to end route is for the data, says Gutierrez.

    Certifications

    Despite the emphasis on traits and approaches to challenges on the job, there are certifications of value to the DevOps engineer. “The Cisco certifications, for example, especially the ones for networking will be helpful since a lot of what you will be doing in DevOps is about data in flight,” says Gutierrez. DevOps engineers need to be mindful of how traffic is moving over the Internet and to and through the data center, explains Gutierrez. Network configuration and network security expertise especially such as is validated through the higher Cisco certifications will be important for the DevOps engineer, Gutierrez adds.

    Application security certifications are also useful as are vendor certifications and courses from Chef, Puppet, and Docker as well as platform vendor training from AWS, Digital Ocean, and the like.

    Individualized Learning

    User documentation and “try me” opportunities for different tools such as containers and configuration management, automation, and deployment tools are helpful for self-starters and people who run into problems or have questions along the way. “People engaging in these kinds of training can simply create local laboratories for these tools on a local machine to simulate the larger application or architecture they are trying to learn,” says Gutierrez.

    In order to learn how to navigate the in-depth areas between the system and application architectures, the DevOps student should consider the books in and around these subjects. Just a few examples include, “DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)”, “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale”, and “Salt Essentials”.

  • The Scalable Path to DevOps Career Training & Development

    The Scalable Path to DevOps Career Training & Development

    “Our company is a premium talent marketplace with on-demand leadership and clients mostly in the Bay Area, Silicon Valley, New York, and other metropolitan areas,” says Tomas Gutierrez, Partner, Scalable Path, a geographically-distributed network of more than a thousand software architects and developers. Scalable Path serves clients such as tech startups and product companies by helping them build software teams and fill technological gaps. Given that Scalable Path assists with software design, its clients most certainly have needs in DevOps approaches. Scalable Path’s Gutierrez informs devopsy.kinsta.cloud about DevOps career training and development priorities and building blocks.

    Foundational Knowledge

    At Scalable Path, a good working knowledge of the seven layers of the Open Systems Interconnect model is important for software engineers who want to work with DevOps approaches. “In order to have a full mental picture of what is happening where, software engineers must have a conversational knowledge across all these layers,” says Gutierrez.

    With any application of software, you will host it on hardware, you will have an OS, and hosts will talk to each other across a network. “The DevOps engineer must know the seven layers involved in order to consider goals for infrastructure as code and to help with software releases, deployment of infrastructure, networking, and configurations,” explains Gutierrez.

    Applicable Traits

    On the job, a good DevOps engineer must be a good problem solver, be able to think outside the box, and have empathy for the needs of the software product and the organization, says Gutierrez. Attention to detail and a security focus are also worth accounting for.

    “Even though it’s good to have formal training, college degrees, and certifications, the right personality, that of an autodidact (one who is self-taught) is key for good DevOps talent,” says Gutierrez. These engineers will examine a technical challenge globally and in its component parts and seek and assemble the tools and processes that will provide a complete solution.

    Further, someone who is empathetic to the needs of the software and the enterprise deploying it will realize when they need to use a simple, cost-effective software deployment without all the extras.

    The ability to direct a focused attention to the details of software engineering is another important trait for a DevOps engineer. Otherwise, programming errors occur that can create issues down the road. “If you don’t architect something correctly, you may end up with part of your architecture failing because you made some mistake in programming,” says Gutierrez. These things can propagate and scale up into bigger issues as the architecture grows.

    It’s also important for the DevOps engineer to be strong in security such that their programming does not expose critical data. It’s about how the programmer constructs the data layer, how they work with the transport layer, and what the end to end route is for the data, says Gutierrez.

    Certifications

    Despite the emphasis on traits and approaches to challenges on the job, there are certifications of value to the DevOps engineer. “The Cisco certifications, for example, especially the ones for networking will be helpful since a lot of what you will be doing in DevOps is about data in flight,” says Gutierrez. DevOps engineers need to be mindful of how traffic is moving over the Internet and to and through the data center, explains Gutierrez. Network configuration and network security expertise especially such as is validated through the higher Cisco certifications will be important for the DevOps engineer, Gutierrez adds.

    Application security certifications are also useful as are vendor certifications and courses from Chef, Puppet, and Docker as well as platform vendor training from AWS, Digital Ocean, and the like.

    Individualized Learning

    User documentation and “try me” opportunities for different tools such as containers and configuration management, automation, and deployment tools are helpful for self-starters and people who run into problems or have questions along the way. “People engaging in these kinds of training can simply create local laboratories for these tools on a local machine to simulate the larger application or architecture they are trying to learn,” says Gutierrez.

    In order to learn how to navigate the in-depth areas between the system and application architectures, the DevOps student should consider the books in and around these subjects. Just a few examples include, “DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)”, “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale”, and “Salt Essentials”.

  • ‘Tis the season to up your speaking game

    ‘Tis the season to up your speaking game

    Well it’s football season in the US, that means Fall is here.  It also means that we are coming up to conference season. No matter what segment of the IT market you live in, there are probably a slew of conferences both local and national/international vying for your attention and attendance. For the overwhelming majority of attendees, going to a conference means watching and listening to others speak on topics of interest.  Maybe this is the year you should really up your game by speaking!

    This was driven home for me last week when I was speaking with the IBM DevOps team.  We were discussing how plans for IBM’s InterConnect 2016 conference were coming along. The call for speakers for this major event is open until September 25th. The IBM team was very pleased that the DevOps stream is tracking among the leading topics for submissions for InterConnect 2016.

    That is really quite a feat when you consider the scope and scale of the event. InterConnect 2016 is IBM’s Premier Cloud and Mobile event, February 21-25 in Las Vegas, and is expected to draw over 20,000 attendees, delivering 2,500 sessions, workshops and labs in 10 major topic areas – including DevOps – and infinite networking opportunities. But it also speaks to both the popularity of DevOps in general and IBM’s focus on it in particular.  In fact, the DevOps stream covers key DevOps adoption paths: Plan, Develop, Test, Release and Deploy, and Operate.  There is a track specifically focused on transforming application delivery with DevOps, and another track called DevOps for Enterprise Systems that will focus on topics related to continuous delivery for two-speed IT including z Systems and Power Systems. There are other streams such as App Platform, Hybrid Cloud, Mobile and Security where DevOps topics will appear. Each track is packed with quality client success stories, technical deep dives, labs, meet-the-expert panels, interactive workshops and more.  What’s nice is the sessions are tagged for interest for management and techies and for skill-level.  There is a ton of content.

    To find out more join me and 14 great DevOps leaders on the crowd chat DevOps: Code, Culture & Community on September 22, 2015 @ 1pm eastern time (60 minutes). You can visit https://www.crowdchat.net/ibminterconnect2016 to add to your calendar or follow along on Twitter #ibminterconnect2016.

    So what does this mean to you?  It means that there are still some great slots available to share your DevOps skills, lessons and experience with the world.  Having spoken at numerous events over the years, I can tell you that participating as a speaker in an event brings a completely new level of learning and understanding.  It is also a great way to meet your peers, other speakers and attendees and expand your own network.

    What should you talk about?  That is probably the biggest obstacle for many people submitting to speak. Randy Newell, Director, DevOps Marketing at IBM, commented to me,”highly-rated sessions are typically DevOps journeys told by peers – shared candidly, complete with the successes and the challenges around technology and culture. Transparency and passion, told from the front lines, go a long way.” I feel that you should speak about what you find interesting. If you find it interesting, chances are others will find it interesting as well.  Also, when you are speaking about something interesting to you, your passion for the topic will shine through and others will feed from and join in your passion.

    In a large show like this, the good news is that with all of the session slots available they have the ability to afford people to explore specific aspects of a subject that might not be available at a smaller event.

    If IBM’s InterConnect is not the event that you choose to share your thoughts and ideas with the world, that is OK too.  Pick another event and submit to speak there.

    Of course speaking at conferences like InterConnect is a great career move, raising your stature and visibility among your peers.  But beyond your own personal benefit, it really benefits the whole community. The best way for us to learn is to share our experiences and stimulate the discussion.

    I realize that some of you reading this may still be hesitant to take the plunge and submit to speak.  If that is your final decision, of course that is OK, too.  You can still be an active participant in sessions by asking questions, joining the conversation. Don’t be a passive conference attendee.  You get out of these conferences what you put into them.

    As for me, I have two or three different speaking topics that I am submitting this week. Some are panels where I will be with key DevOps thought leaders and influencers who are also my colleagues to discuss key trends defining the future of DevOps. Panels are a great way to get your feet wet with speaking at events, btw.

    So what are you going to do?  Share your lessons learned, explore new frontiers, advance the state-of-the-art.  Call for papers for IBM InterConnect 2016 is ending on September 25th. Don’t miss the opportunity to up your game by speaking at the biggest DevOps event of the year! Submit to speak at IBM InterConnect 2016 today. http://www.ibm.com/cloud-computing/us/en/interconnect/