Category: Blogs

  • Live blogging DOES 2015

    Live blogging DOES 2015

    We will be live blogging from DOES 2015. Ericka Chickowski and Alan Shimel are live at the show in case you can’t be here yourself.

  • Microservices, Hyper-Complexity, and Automation

    Microservices, Hyper-Complexity, and Automation

    Imagine building a human being one DNA codon at a time. Sure, you might be able to build a pretty awesome individual. But it would take a long, long time. And you’d only be able to build one. Worse yet, if you didn’t get your person exactly right on your first try, it would take you another long, long time to come up with Version Two.

    Unfortunately, this is exactly the position many companies are putting themselves in with microservices.

    Yes, microservices theoretically enable companies to adaptively recombine their digital DNA to build the increasingly awesome apps. But without better automation, they won’t be able to do so very quickly—or very reliably.

    Hyper-Complex DevOps

    Microservices introduce significant additional complexities into the DevOps lifecycle. Each microservice has its own data mappings, APIs, latency/performance dependencies, etc. So, while microservices may offer genuine advantages in terms of adaptability and re-use, they also multiply the total number of discrete DevOps tasks—especially vis-à-vis test/QA—by at least one full order of magnitude.

    This is a serious problem for shops that aren’t sufficiently well-automated, because any task—or, as is much more often the case, any handoff between tasks—that is not well-automated will quickly turn into a bottleneck.

    The resulting adverse consequences of insufficiently automated microservices DevOps can thus include slow delivery, excessive cost, and mistakes. Worse yet, chronic bottlenecking will likely create a pervasive organizational disincentive that fundamentally undermines the microservices initiative itself.

    What Automation Entails

    Thorough, effective DevOps automation is, of course, more easily aspired to than achieved. To implement the kind of end-to-end DevOps automation required for microservices success, organizations have to get three things right:

    • Process mapping. Effective automation requires an exhaustive definition of process. This exercise is not for the faint of heart—because most organizations have many pockets of ad hoc process at various points in the DevOps cycle. Test/QA tends to be especially variable based on factors such as the delivery pressure teams are under at any given time.
    • Automation technology. Development teams often use scripting and other technologies to automate various DevOps tasks. An overly fragmented automation environment, however, can be difficult to orchestrate and manage. So the move to microservices may necessitate a more holistic integrated automation environment.
    • Leadership and culture. A well-automated DevOps process alone is insufficient for microservices success, because it is unfortunately not true that “if you build it, they will come.” On the contrary, a strong leadership commitment is essential for changing the way people work.

    The application economy is putting development organizations under intense pressure to be more productive and responsive to ever-changing market dynamics. Microservices offer one possible way to respond to that pressure. But microservices won’t work without a much more rigorous approach to DevOps automation. IT leaders may therefore want to focus on automation first and microservices second, instead of the other way around.

    Unless, that is, you only want to build one app using microservices—and then maybe build a slightly better one a few months later.

  • AWS re:Invent – New Releases Drive Cloud Security Innovation

    AWS re:Invent – New Releases Drive Cloud Security Innovation

    The recent AWS re:Invent conference in Las Vegas saw the release of several new AWS services for security. Some of these announcements such as AWS Web Application Firewall and AWS Inspector seemed to take many in the security press and blogosphere by surprise.

    Cloud-native security companies like Evident.io however, weren’t surprised by these announcements. In fact, AWS has been actively partnering with their security ecosystem to create opportunities for partners to innovate on top of these new base services.

    Both incumbent and emerging partners need to remember that a platform is not a product, it is a constantly growing and evolving entity that will continue to adapt as the cloud ecosystem continues to change.

    If you want eternal stability, consider investing in a pet rock. If you want to be part of continuously improved technology ecosystems, then strap in because AWS is the rocket ship of platforms in this space.

    AWS, no matter what they innovate, will encroach on similar value positions of its ecosystem as a matter of existence. However, this is the best situation possible for customers of the platform.

    Customers win out because they receive constant technology innovation and improvement as part of their platform experience, which is something that was never present in the datacenter ecosystem.

    Let me paint some color to what these services mean for the ecosystem:

    AWS Web Application Firewall (WAF)

    AWS WAF enables customers to create filtering rules that whitelist or blacklist application calls coming inbound from the internet towards a customer’s deployed CloudFront CDN resources.

    For example, a customer could write a WAF Rule that filters requests to their web application based on source IP address matching or pattern-matches against the request string.

    If I was running an e-commerce store that only sold products to the US, I would ensure that my WAF rules contained blocking request patterns for IP Address ranges from China, Syria, Sudan, North Korea, and other embargoed countries (and huge sources of malicious traffic).

    While this appears to be a direct attack on some cloud security providers, it really creates a new market path and opportunity for them to deliver their WAF intelligence to the customer.

    Let’s be honest — there’s nothing differentiating about building a big x86 appliance and having it run the rules intelligence for your infrastructure.

    AWS has removed that barrier of virtualizing the appliance and created a direct path for these companies to deploy their core value proposition — curated and powerful rulesets that protect customers from historical, existing, and future attacks.

    Expect to see branded rulesets available through some kind of marketplace or other delivery mechanism here, as that is what customers need.

    AWS Inspector

    Inspector, in our eyes, was the most important announcement in recent AWS history. We’ve finally seen the true convergence of cloud-based security begin to emerge: Continuous API-centric security intelligence accessibility that is pervasively built into the platform’s diverse feature-set.

    With the advent of Inspector, security providers can directly interface to the hosts and applications to provide deep, thorough security visibility for customers without deploying additional third-party agents.

    Let’s face it, customers were already overburdened with agents before they ever got to their security stack, and the value delivered by security agents has been questionable at best in cloud environments.

    Expect security platforms to integrate singular-views of workload-wide security intelligence in order to provide customers a complete picture of their security posture, risk profile, and attack surface.

    Config Rules

    Config Rules was, perhaps, the least exciting of AWS announcements in the security space. Unfortunately for Config-based service interactions, the limitations of the service are still apparent a year after initial launch.

    Config Rules offers no exception, where interesting capabilities for customers to define custom rules that help them understand what changes impact security in their environment are hampered by limited service support, a cost model that is too unpredictable for small customers and of minimal security value beyond the “ping” that happens when rules fire.

    These challenges are compounded by the barrier to entry of writing well-structured and contemplated security rules by a broad audience of non-security experts, which delivers an almost false sense of protection.

    Contrasted with CloudTrail, which gives valuable audit information that makes sense at an operational level, Config Rules anticipates the customer will have strong security experience and operational knowledge to leverage the service.

    But some customers in every user base are satisfied with what we call “good enough” security in the industry, which defines a scope of offerings that barely make the cut to be called security technology.

    The platforms and vendors slinging “good enough” security tend to be at the international buffet, where you get a below-average pizza, a mediocre taco salad, and a poor hamburger.

    Nothing you get leaves you with a feeling of being satisfied, because not enough effort was put into the final product to actually change the way you think about the experience.

    But mature, focused products will always deliver a superior customer experience, and in security that should never be considered optional.

    A vendor who divides their attention between cost management, security, optimization, etc. will never provide the same quality or attention to protecting your infrastructure as a focused innovator in the space can offer.

    Users can expect a waiting period for service support for new AWS services, meaning that your security controls are dependent on Config’s roadmap.

    But security savvy customers, are not keen on waiting for security to grow up around them – they need it now, they need it on 100% of their cloud infrastructure, and they need it to be actionable.

    This is why many will continue to choose the leaders in each security layer over the basic security features tied into the platform itself.

    Expect Config Rules to grow over time – but if Config is any indicator, it will be a long time before Config Rules provides real value for customers on the platform.

    The real value here is that innovators in the security space will continue to fill the gaps left by services in the platform and innovate customer value atop the technology that does make the cut.

    Wrap-Up

    Well, that was a journey – and we only covered three services! AWS re:Invent 2015 was a whirlwind of sessions, 19k participants, and awesome discussions on every topic under the sun.

    It’s hard to believe we have to wait another year to see this massive gathering happen again, but that leaves a lot of time for innovation, new customer success stories, and to sort through the giant piles of swag that everyone picked up in that madhouse of an expo hall.

     

    Author: Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

  • Free Your Metrics

    Free Your Metrics

    If you’re not collecting metrics, how do you know how your organization is doing? Metrics provide the data to get to the root cause of an outage or uncover a bug that would otherwise go undetected. Metrics can also surface trends that are difficult to discern without visualization. Here are some ideas for making the most of the data around you.

    What to measure

    What are the right metrics? As Etsy put it “If it moves, graph it. If it doesn’t, graph it anyway in case it moves later.” Sure, you should collect system metrics like CPU, memory, and disk utilization but those alone won’t tell you how your product is really doing.

    Sell widgets? Measure the rate of widget sales, the time it takes to sell a widget, and the availability of the widget selling system. Serve cat pics? Measure the time to process the images and the size of the processing queue. At the end of the day, these are the types of metrics that indicate how the product is performing.

    Your applications should be instrumented to emit counts and timing for key code paths. This is especially important in service-oriented architectures where a slowdown in one service can impact other services. So, record how long it takes for services to interact with other services so you can pinpoint the source of the latency. If you use a database, there’s a wealth of metrics exposed by the database system that can help determine why a query is slow.

    You should record every code deploy so you can correlate issues with deploys. If memory usage spikes and throughput drops after a deploy – you know it’s probably a new problem introduced by that deploy. Furthermore, you should collect and examine metrics from your pre-production environments so that problems are caught before they go to production and impact users.

    High value metrics

    Non-application metrics are often overlooked but they can provide important insights into the health of the business. Have a support system or call center? Measure the number of new support cases opened. Use social media? Measure mentions and followers. There’s also a wealth of data generated from sales and marketing activities. Imagine being able to correlate an uptick in sales with increased system reliability or the opposite, where outages and bugs are actually causing customer churn. You can’t make these inferences if you don’t have the data.

    Free your metrics

    Collecting metrics is great, but the real value comes from sharing the data across the organization. When you share your metrics, you increase visibility and transparency into the entire stack, which in turn allows you make informed data-driven decisions. So break down the silos and open up your metrics. Put them up on big screens that everyone can see. Put them up in unusual places like the break room. Then watch how people, who wouldn’t normally care about operations, suddenly start paying attention.

    Stay alert!

    You should also alert from your metrics. Response times jump beyond an SLA? Alert on it. Is a queue for a critical part of your workflow high? Alert on it. By reducing the time until detection you can get to fixing the problem faster. After every production outage ask yourself, ‘do I have the correct monitoring in place to detect this problem if it happens again?’ If you don’t, make it a priority to get it in place.

    You’ve got the tools, now go and free those metrics!

     

    About the Author/Eric Heydrick

    Eric HeydrickEric Heydrick is a DevOps Engineer at Praesidio, a big data Cybersecurity Management (CsM) company that bridges the gap between IT Security and Policy Governance in protecting Financial Institutions from cyberattacks. Praesidio’s integrated policies and best practices help Financial Institutions know definitively that they are safe. Eric has 15+ years of experience wrangling computers and building scalable infrastructures. Eric lives in Seattle, WA where he enjoys only the best microbrews. Email: eric@praesidio.com | Twitter: @eheydrick

  • Analytics from a Developer’s Point-of-View

    Analytics from a Developer’s Point-of-View

    As a developer, I have found that most systems analytics tools can be both an important asset and an unnecessary expense. Their usefulness, in my experience, is ultimately determined by the size and stage of the company. If the company is at a low funding stage, the cost of some of the more advanced analytics tools just isn’t practical. If they have the funding, but not the traffic, the benefits of analytics are completely negated by the lack of data to… you know… analyze.

    The same goes for the team size. Analytics tools can be incredibly useful to any size team, however after a certain level of growth a large Development team will likely split into two separate departments: Development and Operations. At this level, these tools tend to be delegated to Operations, leaving Development free to focus on the whole developing part of the job.

    So, your development and operations departments are still on one team (it’s likely both jobs are shared by everyone on the team), and your company has the right amount of funding and traffic to justify the cost and need for a systems analytics tool. But how do you choose from all of the available tools out there?

    This is a question that can bring any developer in a leadership role to their knees because the effects can last for years. I’ve always found that tools that can be isolated apart from the core application itself are always the best choice in this situation because they often take a language agnostic approach and, in case you don’t like them, they can be hot-swapped for another service with minimal effort.

    Being able to easily undo a poor decision shouldn’t be the only measuring stick you use to make your choice. The type of data you can get, and how accessible it is, are both far more important than being able to hit the reset button. As a developer, when dealing with third party applications, there are three things that I look for: usability, accessibility, and visibility.

    Usability

    We all know about usability. It’s a popular buzzword that is thrown around a lot in the startup world but, if you ask me, it is doubly important when dealing with full-stack tools built for developers. Full-stack tools are often more in-depth than standard consumer products. Rather than only requiring good UI/UX on the application frontend, a good full-stack platform requires a lot of foresight in the backend as well. There is nothing that turns me off more than API-as-an-afterthought. Systems analytics tools almost always fall under the umbrella of “full-stack tools” because they are designed for developers and non-developers alike.

    While the application itself should be easy to navigate and use, it is just as important for the API to be clearly documented and logically architected. The more time I have to spend dealing with integrating something that isn’t directly related to the product, the more likely I am going to cut my losses and pick something that was designed with my needs in mind.

    Accessibility

    While a systems analytics platform may be managed by just one person initially, as the team grows, it becomes exceedingly impractical to keep the knowledge isolated. The one thing that will cause my to ditch a tool immediately is a lack of multiple account management. While there are some great business tools for password management, I would prefer that everybody on my team has their own login. This is a major security concern for me. If we let somebody go (or they quit), I would rather delete their account than have to change a password and disseminate it to the rest of the team.

    Visibility

    Having easily viewable data should be a no-brainer for an analytics platform, but you’d be surprised how often I come across tools that do a very poor job at actually doing what they’re supposed to. Showing me pretty graphs and tables isn’t enough, though. I want control of the data. Let me import, export, manipulate, search, and filter it. If the time it takes to get raw information is longer than the time it takes to actually read and understand it, there is something wrong.
    Ultimately, the most useful systems analytics tools I’ve ever worked with do an amazing job at getting out of the way. They don’t try to predict how I want to work and they don’t limit my ability to get what I need, they simply give me the tools to do things my way. While this probably clashes with the common million-features developer mindset, in practice, simple can often be significantly more powerful.

    About the Author/Zachary Flower

    zachZachary Flower (@zachflower) is a freelance web developer, writer, and polymath. He has an eye for simplicity and usability, and strives to build products with both the end user, and business goals, in mind. From building projects for the NSA to features for Buffer, Zach has always taken a strong stand against needlessly reinventing the wheel, often advocating for using well established third-party and open source services and solutions to improve the efficiency and reliability of a development project.

  • Five often expressed obstacles to enterprise IT innovation

    Five often expressed obstacles to enterprise IT innovation

    Business leaders know, for their business to succeed in the years ahead, that their IT and developer teams need to innovate. But surveys show that too often the IT teams may not be able to deliver the innovative value that the business seeks. Have a look out our recent Q&A, The IT mandate: Be a catalyst of business innovation for some more insight on the IT and business innovation gap. The fact is that technology and developer teams can’t do it on their own, they need to operate in an environment that enables innovation. In speaking with CIOs, developers, and others close to the process of creating value with IT a number of obstacles continuously surface. And these obstacles are holding their development efforts back.

    These obstacles include the tight collaboration with development and operations teams, the failure to actually embrace Shadow IT for what it actually is, staying stuck in single mode IT, and oversights in how they are developing mobile applications.

    Here they are:

    Obstacle Number 1: They don’t effectively unleash the power of their developers. DevOps teams are known to grind through technical debt and when they manage to hit on all cylinders they also have very short application backlogs. One way to keep such app backlogs short is to focus on the Minimum Viable Product (MVP). Because the MVP is an application that is, initially, focused only on what it takes to get the job done, and no less or more, developers don’t get bogged down overdeveloping apps that won’t get used. To be clear, MVP doesn’t mean shoddy app, rather it means the minimum app to be productive at the task. With this Spartan approach, development teams can invest no more than is needed into an app, release it into production and see how enthusiastically (or not) it is embraced by the user base. This enables development teams to push apps forward with as little risk and investment as necessary. And then either dig deeper into that app, or move on to another.

    What does that have to do with innovation? Plenty if you consider the amount of time saved from over-developing applications that wont be used and investing that time and effort elsewhere, perhaps apps that will provide value to the organization.

    Obstacle Number 2: They don’t embrace shadow IT. Rather than embrace Shadow IT, many organizations shun the notion of users choosing the tools and technology they need to get their job done. But end users and employees are turning to cloud services and bringing their own devices because these are the devices and services that they know they enjoy to use and they can use to effectively do their jobs. That makes for more productive and happier workers. Certainly not just any old rogue service and device can be used, but the enterprise can watch and vet the services that are safe or find ways to make them safe. A good place to look for this is the Cloud Security Alliance’s Security Guidance for Critical Areas of Mobile Computing.

    Obstacle Number 3: They don’t bimodal. By not embracing two-speed or bimodal IT, enterprises have a harder time allotting resources to strategic development and IT efforts. In bimodal IT there are two modes, one mode is focused on quickly delivering the applications the enterprise most needs to compete and be effective while the other mode is focused on the infrastructure services and API development and management.

    A good overview on bimodal IT can be found here in our post Bimodal IT and Remodeling Traditional IT for Greater Agility.

    Obstacle Number 4: There exists an average to poor business to technology interface in the organization. In too many organizations there is a lot of collaboration within the technology groups, such as operations and developers, but not enough interfacing with the business teams. For better outcomes, there needs to be tighter collaboration between DevOps and the business through continuous feedback on current and future objectives. This way DevOps teams know what the business priorities are and can develop to them more effectively.

    Obstacle number 5: They aren’t focused on the context within mobile moments. The world of IT has gone mobile and will someday go wearable. This is more than just a mere form factor trade; it is creating a profound change in the way we interact with our apps. When we sit down to work on a laptop, we are usually settling in for a nice stretch of work time. However, when it comes to phones and wearables, we are usually working in short instances. We are sending a text, answering one email, or capturing one or two new data points about a client for entry into the CRM app. Developers need to focus on providing users apps that work in the same way too. That is they need to develop apps that provide users the data they need based on short device interactions and hopefully context of what they’re doing. If the user were at a clients’ office, for instance, and the rep launces the CRM app, it’d be ideal if that customer profile launched by default with the app. If the user is involved in a certain workflow, other items that are commonly taken care of at the same time would also ideally be suggested.

    While these obstacles may sound simple, they can be quite transformative to the way your business-technology teams will develop, collaborate with the business, and hopefully provide more innovative services.

  • Building an agile data tier improves devops efficiences

    Building an agile data tier improves devops efficiences

    Meet the modern day agile data tier – improving DevOp efficiencies
    DevOps teams are constantly in the high-pressure environment of reacting to real-time market and industry changes and launching new features and functionality to maintain competitive positioning. Accelerating development is simply not possible if scalability is an issue. Scaling databases has proven to be especially challenging. Software rollout cycles can easily get delayed because of the complexity of coding for database scale out. At the same time, a lack of understanding and visibility of app behavior can also result in slow apps getting launched. Without intense technical development, databases can be the function hindering your apps – but they don’t have to be.

    DevOps: Resist the urge to do-it-yourself
    As pressures mount to deliver more and more applications, DevOps teams can benefit from creating an agile data tier that seamlessly addresses the most technical, yet burdensome, administrative functions of databases and lets software do the hard work instead. It is now possible for DevOps teams to offload database scalability and failover without increasing app complexity and enable a zero downtime experience along the way.

    Database load balancing software enables this agile data tier. It acts as an abstraction layer between apps and databases, getting developers out of the business of programming for the database and letting them instead spend their time on more strategic projects. Having an agile data tier profoundly reduces development time, taking dev cycles from months to weeks.

    The last thing any developer wants is for an app to become more complex and burdensome – both are big risks when dealing with databases. But there is more to database load balancing then other kinds of load balancing. Replication-aware load balancing, read/write split and caching functionality are all crucial for database scale out. But designing those functions directly into the app is time consuming and repetitive. Designing for high availability just adds to the complications.

    With database load balancing the idea is to take this burden off of the app – and therefore off the developer – resulting in faster rollout, better scalability, and the ability to refocus time and attention to features and functionality that contribute to the business. What developer woke up this morning craving to spend a good chunk of their time on programming for database scale out?

    Making applications fundamentally less complex and improving their availability, database abstraction solutions that provide database load balancing such as ScaleArc, the company I founded deliver on the promise of scale and always-on app availability. Such software makes application design far simpler, leaving more time to develop and build applications that drive business advantage.

    About the Author/Varun Singh

    Varun-SinghAs Founder and Chief Technology Officer, Varun Singh leads ScaleArc’s product development and technology strategy. He also served as ScaleArc’s CEO from March 2009 to September 2013 and was responsible for impressive company growth and customer acquisition of top brands including Tesla Motors and Zuililly with limited if non existant marketing or sales budgets. Varun is a technologist with broad experience in several fiends, from running Linux-based BBS sytems in the pre-Internet days to writing about technology and open source software at PC Quest, CHIP, Digit and Network Computing. He was responsible for creating India’s top online technology brands and his team kept CNN India running as the only uninterrupted news network during the Mumbai terrorist attacks.

  • Coming to DevOps Enterprise Summit 2015? Must attend IBM sessions and Night at the Garage event!

    Coming to DevOps Enterprise Summit 2015? Must attend IBM sessions and Night at the Garage event!

    DevOps Enterprise Summit 2015 is next week. Though only in it’s second year, it is a conference that any technical professional can get excited about, and is an event that IBM is proud to sponsor. Three days of discussion span topics from product integration, to agile and lean concepts, and how to start implementing DevOps and continuous delivery at enterprise scale.

    We are bringing the full force of IBM DevOps to #DOES15 this year, with subject matter experts speaking in two keynotes and two sessions, and bringing even more knowledge to booth #8 to show IBM DevOps solutions in action. If you are going to be at DevOps Enterprise Summit this year, make sure you check out:

    • DevOps and Innovation at USAA and IBM from Dibbe Edwards, Vice President Development, DevOps for Hybrid, IBM and Michael Bueche, Assistant Vice President IT Operational Excellence, USAA on Monday morning from 11am-12pm in the Grand Ballroom. Dibbe and Michael will discuss how DevOps initiatives combined with automation and culture changes are driving quicker user feedback and overall software delivery.
    • Act like a Start-Up, Scale for the Enterprise from Rachel Reinitz, IBM Distinguished Engineer and CTO, IBM Bluemix Garage, Dr. Angel Diaz, VP of Cloud Technology & Architecture, IBM, and Kristal York, Executive Mobile Strategist, PointSource on Tuesday afternoon from 2:15-3:15pm in Bayview A. Rachel, Angel and Kristal will discuss why and how IBM is implementing DevOps and how IBM’s global network of Bluemix Garages is providing the knowledge and experience that enables our clients to transform into digital businesses and deliver disruptive innovation.
    • Test Automation For Mainframe Applications from Rosalind Radcliffe, IBM Distinguished Engineer & Chief Architect for DevOps and CLM on Wednesday morning from 9-10am in the Grand Ballroom. Rosalind will be talking about how to apply shift left testing to mainframe applications, including integration testing and virtual services to improve early testing.
    • Organization Design Panel Discussion with Mustafa Kapadia, IBM DevOps Service Line Leader, as the facilitator join Jason Cox, Director, Systems Engineering at The Walt Disney Company, Jeff Einhorn, Senior Group Engineering Manager at Target, Jeff Raffo, Director – Personalization Technology at Nordstrom and Jim Penny, Solutions Director at IBM on Tuesday afternoon at 2:15 pm in the Exhibit Hall. The group will discuss about Organization Redesign and how some of the largest enterprises have been able to achieve this transformation. You may also get a box set of our For Dummies books or a limited edition IBM DevOps t-shirt with your visit!

     

    Picture1

     

    Finally, if you are looking for an immersive DevOps experience that includes complimentary beer, wine, local cuisine, and live entertainment, join us for a Night at the Garage! IBM is providing transportation on Monday night, October 19, from the Hyatt Regency SF to the Galvanize building that hosts the IBM Bluemix Garage, where you can network with other DevOps enthusiasts and witness the art of the possible firsthand at 5 interactive workstations. Register now to attend, space is limited! We look forward to meeting you there.

    About the Author/Saleem Padani

    SaleemPadaniSaleem Padani has 20-plus years of technology and business experience in product and application development, enterprise architecture, service delivery and solution marketing. Currently, he is responsible for overall go-to-market strategy and execution for IBM DevOps and Enterprise modernization capabilities for IBM. Follow him on twitter at @spadani1

     

  • Survey on Modern IT – We Need Your Opinion!

    Survey on Modern IT – We Need Your Opinion!

    Change is the only constant in the world of IT. Developers, ITOps and the DevOps community are undergoing significant changes in needs, processes and services. This survey will provide better understanding of how the latest trends are impacting innovation, security and your team.

    This survey is sponsored by Apcera, a highly secure, policy-driven platform that lets enterprises innovate at speed with full confidence and trust. You can learn more by reading an interview with Apcera CEO, Derek Collison, on Container Journal.

    The survey is under 20 questions and takes about 5 minutes to complete. Share your thoughts on what is leading innovation, what stands in your way and how new technologies are are influencing the IT landscape.

    By taking the survey, you’re helping the entire DevOps community better understand where we stand and where we’re headed. As always, the results will be released when the survey period is complete.

    Take the Survey

  • DevOps Connect: cdSummit at Austin Innotech

    DevOps Connect: cdSummit at Austin Innotech

    Last week I was down in Austin, Texas for the DevOps Connect: cdSummit @Innotech show. With almost 1900 people registered for Innotech, we had a solid 150 folks specifically for cdSummit.  I think it fair to say that the attendees got their money’s worth!

    The morning started off with a great presentation by Jez Humble.  If you are talking CD, who better than the guy who literally wrote the book to kick things off.  Jez never disappoints and he didn’t last week.  His presentation is below.

    After Jez, Andy Pemberton of CloudBees presented.  Andy has a great delivery and I have seen him present before. It was a great engaging presentation and it is below for you to view.

    Following Andy we were very lucky to have David Lindquist, IBM Fellow, VP of Development, Mobile and Cloud DevOps. David gave us some great insight into IBM’s own journey of using DevOps to make an enterprise work at startup speed. Again his slides are below.

    We then broke for a great, relaxing lunch break and to give our attendees a chance to explore Innotech. There was a demo theater on the show floor featuring Jenkins, BlueMix, New Relic and AppDynamics demos. Innotech also featured a “Women in Tech” show and CIO roundtable with some great content.

    After lunch we broke into two rooms in a dueling track format. We have enclosed those below. My favorites were from the great, welcoming and amazing Austin DevOps community. Ernest Mueller previewed the talk he is giving at DOES next week.  James Wickett, one of my heroes from the Rugged DevOps movement did a great job on his session and Boyd Hemphill brought the house down closing out with his HomeOps presentation which I found witty and incredible.

    All of the speakers were really good and the feedback from the attendees echoed this.  Many thanks to our sponsors, CloudBees and IBM as presenting sponsors, AppDynamics and New Relic as gold sponsors. Most of all thanks to all of the people who came out and spent a great day with us! We are holding the next cdSummit on December 3rd in Los Angeles and if you are interested in speaking, attending or sponsoring, contact me at editor@devops.com.  We will announce more details shortly.