Category: Blogs

  • “Culture” isn’t a swear word

    “Culture” isn’t a swear word

    7889902_orig

    I’ve heard a number of lazy criticisms of DevOps recently particularly where individuals talk about culture and that gets my goat.
    “It’s fluffy”
    “It’s in-actionable”
    “DevOps is just automation”
    “Cultural change isn’t relevant in a bank – its a term used by the Facebook’s of this world”

    I think part of this is the continuing confusion over what the term means, along with DevOps being used as an umbrella term for a dozen different other things (Continuous Delivery being the most prevalent).

    I’ve talked at length about what DevOps is to me in my blog so I’m not going to cover that again. However, I am going to talk about this wholly word “culture”.

    Let me start with a great definition of what culture is (it’s not my quote but I wish it was) – apologies I forget the source.

    “Culture is what you do when there is no one around to tell you what to do”

    I think that’s brilliantly simple and bang on the money.

    DevOps is concerned with bringing two disparate groups together (unsurprisingly Developers and Operations) and encouraging empathy and collaboration between them.

    Nothing in that talks about automation.

    The companies with the right culture between Dev and Ops might land as automation as a solution to curing some of the challenges of unshared incentives and goals.  However, it doesn’t predicate it.

    A strong DevOps culture might turn to Continuous Delivery as a process solution to meeting their demands for an increased pace of change. But again it doesn’t predicate it.

    Its really important that people understand the differences and goals between DevOps, Agile, Continuous Delivery etc.

    They all very closely relate and link but they are different things (take a look here for a glossary).

    Back to those criticisms…

    “It’s fluffy” – Culture is closely linked to human behavioural patterns and humans are very different. So its a fairly loose term but does it make less important? Not for me. How your employees and colleagues behave and interact is THE most important thing in a company. There are a squillion clichés out there about how your employees are the most valuable asset but its absolutely true. Great people and accomplish great things. Great technology is nothing without great people.

    “It’s in-actionable” – again this is a very lazy criticism. Culture is actionable its just hard to change. Changing the way you recruit, sitting people together in cross-functional teams, not micro-managing, encouraging lunch & learn presentations etc are all actionable ways of affecting culture.  Culture is hard to change though as we are dealing with people. People have different reactions to change and are sometimes difficult to second guess. It takes time and effort but that doesn’t make it in-actionable.

    “DevOps is just automation” – think I’ve done this to death but for clarity…the right culture could well lead towards automation as a solution.

    “Cultural change isn’t relevant in a bank – its a term used by the Facebook’s of this world” – why is having high performing people in a high performing environment only relevant to the unicorns of this world (i.e. Netflix, Facebook etc)? Its a daft comment in my eyes.

    Besides who are the companies earning the big bucks these days? Oh yeah its not the banks it’s Facebook, Google etc…

    Characteristics of a DevOps culture

    Here are my top twelve characteristics of a DevOps culture. How far are you off?

    • 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.
    • Seek 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
  • Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Organizations are increasingly migrating to cloud-based services to handle sensitive data and business processes, meaning security teams need to carefully review and understand what security controls are available to help protect them.

    Given the pace of cloud adoption, security teams need to increase security automation efforts and employ tools that can better secure their cloud assets through improved visibility.

    SANS is hosting an informative webcast on Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) to present the findings from a new survey that examines the organizational use of public and private clouds and outlines best practices for assuring a robust security posture.

    The webcast is scheduled in conjunction with the release of the highly anticipated SANS whitepaper on cloud security titled Orchestrating Cloud Security (PDF), written by analyst and network security specialist Dave Shackleford.

    The whitepaper presents the results from a survey 485 IT professionals who use different cloud providers and service models for a variety of business needs, including collaboration services, email, managed services, backups for disaster recovery, and other common use cases for cloud services.

    Although cloud services provide the functionalities businesses need today, the survey reveals that they also come with inherent security risks.

    The SANS survey found that 40% of the respondents acknowledge they process sensitive data in the cloud, and are facing increasing challenges related to access control, configuration management, compliance demands, overall visibility, and the implementation of security controls.

    New technologies are emerging as part of the security-as-a-service (SecaaS) model, which are security-oriented cloud-based services that integrate with provider platforms to protect data in cloud ecosystems.

    “Although many controls are still managed internally, SecaaS is emerging as a viable means to enhance security in the cloud environment. Security teams should start considering the use of SecaaS options when designing and architecting cloud security models,” the SANS survey notes.

    In the upcoming webcast, Shackleford will be joined by myself (Evident.io’s Andrew Maguire), Intel Security’s Margaret Diego, CloudPassage‘s Sami Laine, and Mark Painter from HP Enterprise Security to discuss:

    • How organizations use the cloud
    • What types of information they store in the cloud
    • What concerns they have about data security
    • How much they rely on cloud service providers and what difficulties they face
    • What security and data protection technologies they use in the cloud environment
    • How they manage cloud users
    • And much more

    The SANS survey clearly highlights and validates the challenges of cloud migration across companies of all sizes. Organizations moving workloads to cloud architectures such as Amazon AWS understand the flexibility and cost efficiencies gained – but often struggle with new best practices and the shared responsibility needed to maintain a secure cloud-computing environment.

    The porting of traditionalsecurity technology and Agent-based solutions used in the past do not translate well to cloud environments, leaving customers with too much data and poor visibility into critical service configuration or controls that could eventually lead to compromise.

    Webcast attendees will be among the first to receive the whitepaper. Join us Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) for this timely and informative webcast!

  • DevOps Chat: Randy Newell, IBM InterConnect 2016

    DevOps Chat: Randy Newell, IBM InterConnect 2016

    Last week I had a chance to sit down with Randy Newell, Marketing Director for DevOps at IBM.  We talked about the buzz starting to build around InterConnect 2016 this February in Las Vegas.  The call for speakers is open until September 25th.  Randy and I spoke about last years event and what to expect this year,
    Below is the audio of our conversation and below that is the transcript if you would like to follow along.  Enjoy!

    Alan Shimel:                Hi. This is Alan Shimel and this is another DevOps chat. Our guest today is a friend of mine, Mr. Randy Newell, Worldwide Marketing at IBM. Randy, I’m pretty sure I messed up your title. Why don’t you correct me for our audience?

    Randy Newell:             Sure. I’m Marketing Director for DevOps at IBM.

    Alan Shimel:                Fantastic. Randy, we’re on today to talk because the buzz has already started building for InterConnect 2016, which is February 21st though the 25th, if I’m not mistaken, out at the MGM Grand in Mandalay Bay Hotels in Las Vegas. Is that correct?

    Randy Newell:             That’s right, Las Vegas, Nevada, USA.

    Alan Shimel:                Welcome to fabulous Las Vegas. Randy, for a few people in our audience maybe who are not familiar with InterConnect, can you give us a quick background on the conference?

    Randy Newell:             Sure. IBM InterConnect is IBM’s Premier Cloud and Mobile Conference. The first time event was actually last year. It was a mash-up of three different events that IBM has been doing previously, Impact, Pulse, and Innovate, all having different angles to them. We mashed them together and then kind of put in an overall mobile and cloud focus on it.

    We ended up having somewhere in the neighborhood of 20,000 attendees last year, and delivered an enormous amount of curriculum and content, about 2,500 sessions. It was a tremendous success. So we’re excited to be back at it and planning it now for next February.

    Alan Shimel:                Randy, near and dear to the hearts of our listeners here on DevOps.com, under those 2,500 or so sessions there was a tremendous amount of dev-ops related content and curriculum at the show, wasn’t there?

    Randy Newell:             Yes, there was. I think in all the number was something like 385 dev-ops sessions, and that includes presentations, labs, workshops, et cetera. So it was one of the major streams. I think we had five total streams last year. Dev-ops was one of them. Streams is just conference vernacular for a grouping of tracks. We’re essentially doing a similar approach this year, so there will be a similar major presence for dev-ops, somewhere in the neighborhood of 300 or 400 total sessions.

    I think what’s interesting about this year is you’ll actually see dev-ops in addition to being in its own stream, its own set of tracks, will actually permeate a number of the other streams as well like hybrid cloud, mobile, Internet of things, security, et cetera. So that’s kind of neat because we’ll see it put into the context of some of these other streams.

    Alan Shimel:                And that very much is in line with where dev-ops is in the market today. It seems to be everywhere. Randy, for those who are listening, I wrote an article just the other day about “Up Your Game” when you go to these conferences. Rather than participating by listening, participate by speaking. The call for speakers is still open, correct?

    Randy Newell:             That’s right. It actually closes out on Friday, September 25th. So those who are reading your blog and taking the challenge to get themselves out and present this year, we really encourage them, if they’ve got a good story of their dev-ops journey, to really consider putting together a response to that call for speakers and getting that submitted by this Friday, by September 25th.

    Alan Shimel:                Randy, I’ve spoken to dozens if not more of people who say, “Oh, why do people want to hear about me? What do I have to say to people?” Can you give us sort of a peek into what are the kinds of stories or presentations that you guys are looking for, for InterConnect this year?

    Randy Newell:             I think that’s a great question. First of all, just maybe a minute on the way that we’ve organized dev-ops at the conference, the way that the stream looks. Dev-ops is the overall stream, and then think of it organized into a couple of interesting tracks. One really positions dev-ops overall as an enabler of transformation. So if you’re thinking about submitting and you have stories about the way dev-ops has helped transform application development delivery generally or transform for faster innovation, which is really where we’re seeing a lot of these come in now, consider that particular track.

    Then there are a series of tracks that are knitted together that dive into what we refer to as option paths or phases of the software delivery lifecycle, so focus on plan, dev, test, deploy, operate. So if you’ve got a particular story in that space, then I would encourage you to think about that context.

    Then we’ve got a track that actually addresses the unique considerations of dev-ops in large enterprise, where you’ve got multi-platform environments, so considerations relative to Z mainframe, for example, power environments, and get into neat concepts like variable speed IT, bimodal, those sorts of concepts within that context.

    Then of course the other tracks that I mentioned are streams on hybrid cloud, on mobile, security. So first I’d think of, “Hey, do I have a story that fits particularly well into this framework,” not that you have to work within that framework, but it would give you some context.

    Then I think what we saw playing particularly well last year, so conference sessions that end up getting scored particularly well are about your dev-ops journey, and think of sharing it at really one of two levels, because InterConnect is very broad and we should probably talk about that a little bit. But what’s interesting is we have management topics and we have technical topics. So I would generally think about whether you’re grouping your story into one of those two.

    The management topics and technical topics can actually play against everything that I’ve mentioned so far, but the important thing is sharing the journey. What were your successes and also your challenges? Envision yourself sitting in the seat. Am I learning something? What am I learning from this particular session? So I’m listening to the presenter. Tell me about their journey and not just, “Hey, we hit the following KPIs around speed or quality or engagement,” or what the particular metric might be for your particular execution, but what were the challenges politically, especially cultural issues. How did we get that first starter project through? What were the challenges on scaling for the next project?

    I think it’s those sorts of things that work particularly well. I would encourage people the way to get your track approved and, importantly, that in most cases will get you a free conference pass which is worth a couple thousand dollars, which is good, is to get specific about the learnings, the metrics, what you were able to accomplish with some good quantitative aspects behind it.

    But as I indicated, don’t forget some of the qualitative aspects that would say, “Hey, while this was dev-ops and was largely about increasing speed or increasing quality, what did it allow the business to do?” Because in the end we were after gaining some business agility or some increased market speed, and what did that mean. Increased market share. Were we able to launch a new business venture? Did we increase customer sat? Those sorts of things come out extremely well, especially if you’re talking some of the management tracks.

    Then if you’re looking at a technical track, really peel back and look at some of the leading edge implementations and use cases. I think that’s where we’re going to see a lot of excitement.

    Alan Shimel:                Absolutely. Randy, I always like to tell people talk about what you’re passionate about, and chances are there will be other people who are passionate about the same thing, and birds of a feather will flock together and they’ll join in your passion. There’s nothing better than a presentation where you have a room full of people that are passionate about the subject that’s being presented. It makes for the best presentation.

    So I highly, highly encourage you. If you are thinking about it, dipping your toe in, whether you’ve spoken before at conferences or not, if you’ve got something you think you want to share with the world and talk about your dream and your path and your journey, as you said, Randy, it is open till September 25th, the call for speakers.

    I believe you can get to it at www.ibm.com/cloud-computing/us/en/interconnect. But don’t worry if you didn’t write that down. We do have it up on our website at DevOps.com. You can find it there under an article I wrote called “Up Your Game: Speak at a Conference” or something to that effect.

    Randy Newell:             You can also just use your favorite search engine to just search on IBM InterConnect 2016 call for speakers.

    Alan Shimel:                That sounds too easy.

    Randy Newell:             It might take you right there.

    Alan Shimel:                Yeah. That’s another way. Randy, all work and no play makes us dull boys and girls. The other great thing about InterConnect is it’s such a great networking event. I don’t mean switches and routers. I mean human networking. Talk a little bit about some of the social activities maybe from last year and what we might look to see this year.

    Randy Newell:             I think one thing to note and obviously anybody that’s paying attention to DevOps.com knows that there are an awful lot of conferences that are going on in the industry. I think what’s neat about InterConnect and what’s maybe a little bit different than some of the other conferences is the breadth of the conference itself.

    As I indicated earlier, we intentionally blended a number of prior events into this, and then obviously have extended the curriculum to be largely around mobile and cloud. Surprise, surprise, it’s about the enterprise. That’s where IBM plays. So it’s a very rich enterprise environment.

    But what really hit home last year, we used to have a prior event called Innovate, which was a dev conference. We had another conference called Pulse, which was kind of an operations conference. We had another conference that was Impact, which was largely about middleware integration concepts, et cetera. All of those, every one of them had 4,000, 10,000, 12,000, and now this is combined and we’ll do well over 20,000 at this event this year.

    When you put all those together and you have a topic, especially like dev-ops, and we might have addressed in prior years and it might lean towards a dev topic. It might lean towards an ops topic, depending on which of these events. When you put this attendance base together, it really is exciting because you’ve got major enterprise customers that are sending in some cases dozens if not over 100 attendees from a given organization, and they’re from different parts of the organization, yet you’re hearing the same major conference topics. You’re able to segment your path, your personal roadmap through the event to get what you want out of it, but you’re able to basically go share experiences as well.

    So if you want to go onto the show floor, going back to your question about what’s going on socially, the mix of sessions and labs and workshops and going out onto the show floor, whether it’s demos and touch and feel and let’s build an app together and those sorts of things, especially when you do it with your colleagues who might represent your dev-ops team. That’s kind of cool.

    Alan Shimel:                I agree, Randy.

    Randy Newell:             We do some neat stuff, too, and I know you were there last year and I appreciate your collaboration around the event. IBM knows how to throw a party as well. Last year we had Aerosmith there and we took over the MGM coliseum. Obviously it was sold out. I think it was well over 12,000 or 13,000 people. And it rocked.

    We end up kind of blending what turns out to be very long days with lots of excitement and lots of technology and lots of learning and sharing and networking, but there’s an awful lot of play time, and Vegas is certainly a great place to do that. There’s certainly an awful lot of distractions and opportunities for –

    Alan Shimel:                For those who want to partake. Randy, I will just mention as a participant last year, as an attendee, as an observer, what I really loved about the InterConnect experience was it is a really big show, and sometimes though one can get lost in a really big show. What I liked about InterConnect was the keynotes were by the kinds of luminaries you would expect to see at a show of this magnitude. These were real headliners, not just keynotes, headliners.

    But because of the breadth and width of this show, almost 400 dev-ops tracks, if there was a particular aspect that you wanted to explore and take a deeper dive into – so many shows have dev-ops and three-quarters of the things are: what does dev-ops mean to me? What is dev-ops? Why should you care? At a show like InterConnect you could slice minute slices into stuff that you’re really important on. How can I facilitate better continuous delivery and better feedback loops in a banking scenario, in a financial institution scenario? How is a Fortune 100 bank delivering mobile applications based upon mainframe technology?

    Those are the kinds of deeper dives that you’re not going to get at a show that doesn’t have that depth, doesn’t have that breadth. So I highly recommend it for that reason.

    Randy Newell:             I don’t think we’re unique in this, but I think what we’re getting better at with the InterConnect Conference and IBM conferences in general is tagging the content. So if you go on to your personal agenda builder as you’re readying for the conference, you can build yourself a personal track based on: am I looking for management tracks on this topic? Am I looking for technical tracks? When I’m thinking about how advanced the tracks are, am I signing myself up for novice stuff? Am I going for double black diamond? Those sorts of things.

    So I think there’s ability in all of that breadth to actually really find a personal track through it. I think we uncovered some gems last year based on ratings, based on attendance, and of course our updating that based on what we’ve been hearing over the last year, since the last conference, is we’ve evolved in the dev-ops space from a lot of clients trying to understand what dev-ops is, and we still answer that question and will answer the question this year with sessions that are designed for that, but we’ve seen customers evolve not just from doing pilot dev-ops projects or drilling down in a particular adoption path area like deployment automation or agile planning or something like that, but to actually now start to build full integration across the lifecycle so that they’re actually achieving real continuous delivery. That’s really cool.

    For the clients that haven’t gotten to that point, there becomes a question that says: how do I get started? One of the things that we delivered last year and I think you’re aware of is we ran some workshops. The workshops were designed to do a dev-ops assessment. Where are you on your readiness for dev-ops?

    These were kind of cool environments where you’d bring in either a single client and you’d actually get 10 or 12 people in the room all from that client, or you might run it in a multi-client environment and just a common topic. But the point was you do an assessment right there live as a workshop, and these things are run by pretty heavy-duty folks from IBM. These are distinguished engineers. They might be IBM fellows. They might be global services partners or directors who bill out for a fair amount of money. You’re talking about live, basically included in the price of your conference fee, consulting on how ready are you for going towards dev-ops and getting to a point of, “We understand where we’re broken and where the right starting point is.”

    We’re going to keep building on that for this year. So we’ll continue to see those types of workshops, like I just discussed, but we’ll actually progress it and blending it with some of the stuff that we’re doing now in our Bluemix Garages, for example. I don’t know if you’ve heard about this, but we’ve opened up a whole host of Bluemix Garages and these utilize a neat approach. It’s a startup methodology that they use.

    What we’re finding is that enterprise customers are coming into that garage environment, and they’re understanding how you can very rapidly use this kind of startup culture as well as a kind of rapid methodology that’s there, to go from ideation to MVP in a matter of a couple of weeks. If you’re talking about line of business, being able to see that kind of responsiveness, that’s exciting, and that becomes kind of the way that you can go back to the enterprise and scale that sort of startup culture within the enterprise environment. We’re trying to harness that.

    So being able to put that kind of environment into InterConnect to say, “Let’s go from your assessment,” if that’s where your readiness is, to understand where you are, for those who have progressed and want to understand some of the design thinking and aspects that go into this very rapid movement from ideation to MVP, so that you can start to show this to your business stakeholders. That’s a neat thing that we’ll be experimenting this year as well within the context of InterConnect.

    There are a few things that have enabled that. Last year we were working off of a beta version of Bluemix, which is IBM’s platform as a service. Bluemix together with SoftLayer have become a really pivotal part of the way that we can deliver dev-ops in a hybrid cloud environment. Bluemix has since gone GA last summer and is now actually the fastest growing platform as a service in the industry right now, and that’s the tip of the arrow for doing rapid dev-ops environments. So you have this immediate standup environment that’s available on the Bluemix platform, and then you have this integrated experience for your dev-ops team within that environment, and able to go right from build to test to automated deployment instantaneously, literally a one-click environment within that context.

    So that’s something that we’re going to leverage in the InterConnect environment, to be able to show that speed with which you can get to that initial end.

    Alan Shimel:                Fantastic. Randy, we’re way over time here, so I’m going to have to wrap it up. You know what? We’ll be doing more chats as we get closer to InterConnect certainly.

    Just a quick reminder again, if you listened to nothing else today, if you want to speak at InterConnect September 25th is the deadline. Don’t miss it. There are a lot of openings, a lot of slots. So I encourage everyone to share their journey and apply.

    Randy Newell, thank you very much for giving us a little InterConnect 2016 insight today. We look forward to having you again as a guest on our show.

    This is Alan Shimel for DevOps.com. Till next time, thank you very much.

    Randy Newell:             Thanks, Alan.

  • DevOps Chat: Varun Singh, CTO of ScaleArc

    DevOps Chat: Varun Singh, CTO of ScaleArc

    singhI recently had a chance to sit down with Varun Singh, CTO and founder of ScaleArc. ScaleArc was recently named a Gartner Cool Vendor and is the leading provider of database load balancing software.

    Varun and I spoke about why IT leaders need to ensure that their databases are performing optimally.  On top of that Singh has had a colorful career in India as a pioneer in the Internet.  You can listen to our conversation and follow along with the transcript. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505149″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”450″ iframe=”true” /]

    Alan Shimel:                Hi everyone, this is Alan Shimel, editor in chief of DevOps.com. Very happy to be joined today by our guest, Mr. Varun Singh, founder and CTO of ScaleArc. Varun, welcome to our webcast.

    Varun Singh:               Thank you, Alan. Thank you for having me today, it’s going to be fun.

    Alan Shimel:                I think so. So Varun, we were talking a little bit before we went live, or recorded, as the case may be, and you were giving me a little bit of your background. You’ve had quite an interesting career working on OS/2 Warp and BBS’s in India, running the first BBS based on Linux in India and hosting a TV show there as well.

    Varun Singh:               Yep, yep. I’ve really sort of aimed for diversity, if you want to put it that way, in my career. I’ve tried anything and everything. Been a writer. Been a journalist, sort of reviews and everything else. Started a website called TechTree.com, which is now like the number one tech website in India at this point in time, and a whole bunch of other stuff. Joined CNBC sort of at the peak of their build up and joined them primarily as a tech editor, but they wanted me to be the CTO, so I did that sometime. Built a whole lot of websites with them, and when we did that, essentially learned the value of how to scale databases. And from there came the idea of ScaleArc.

    Alan Shimel:                Excellent. So Varun, excellent lead in for our audience who may not be familiar with ScaleArc, can you give us a quick background?

    Varun Singh:               Sure. ScaleArc is database load balancing software. We essentially ship you a virtual machine, and that virtual machine includes the database load balancing software that let you scale, provide a zero downtime environment, and essentially make your transactional apps completely zero downtime. This is the kind of tech that pretty much Google, Facebook, everybody else have had within their networks, because they’ve built it for themselves. What we’re doing is building it for the rest of the world.

    Alan Shimel:                So as some others have been wont to say, the CoreOS people, you’re bringing sort of Google-like experience to the masses.

    Varun Singh:               Yes, at the database layer, yes. So CoreOS is doing it essentially, the OS layer, and there’s a whole lot of stuff that’s going on in the container world, which is all very, very exciting and we’re participating in that in someway as well. But essentially what we do is we sit at the transaction box. So applications and websites, they connect to us with an abstraction layer, and once they connect to us, we then go ahead and establish connections to multiple database servers in the background and make sure that no matter what happens, that application gets its transactions through.

    Alan Shimel:                Excellent. And Varun, ScaleArc is sort of a six-year overnight sensation, right? You guys have been around for some time since 2009?

    Varun Singh:               Yep, it took us about 2.5 to 3 years to sort of build the tech itself, because it’s pretty complicated to build what we’ve built, because we’ve built essentially the world’s first transparent database engine. If you look at the four patents that we filed in 2010, they’re all about transparency and how we’ve basically made this possible for any and every app. So all an app has to do is just transfer its connection over to us and immediately they get access to an entire cluster, they get access to zero downtime, they get access to deep SQL  analytics, and all of that is available to them as part of that one single package that we provide.

    Alan Shimel:                Excellent. So Varun, our talk today is really aimed at C-level, VP manager level people. Why should – without getting too far into the weeds on the technology or feature set, why should executives care about what ScaleArc is doing and what problem are you solving that executives care about?

    Varun Singh:               Sure. So at this point in time I’m sure a lot of executives are looking at how to migrate to the cloud. The moment you go to the cloud you’re essentially running into smaller machines, you’re running into unpredictable arrangements windows, and you also have to worry about how to aggregate capacity across multiple machines to be able to make your performance numbers.

    A lot of applications that are running on very large servers on prem don’t have a way, don’t have a path into the cloud right now. So ScaleArc is basically the thing left that’s the last step in being able to migrate to the cloud as far as large mission critical database intensive apps go. So that’s the first thing that we do.

    We’re making it a lot easier for your application developers to develop these apps and not have to worry about the HA piece, not have to worry about the failover piece and all those things. And that makes your developer’s life so much easier. We provide you a lot of APIs and all those APIs let you automate pretty much all of these functions. You could go ahead and do a rolling upgrade. You could do a rolling patch. All of that can be automated, and you can do all of that using our S API’s that are provided by us.

    Alan Shimel:                Excellent. So Varun, when you guys typically – well first of all, is it mostly larger enterprises that are looking for this kind of thing or is it across the board?

    Varun Singh:               It is across the board, but we’re specifically at this point in time targeting larger enterprises. So some of our largest customers are like Dell.com. So every single transaction on Dell.com works with us and we’ve been with them through the last two Black Fridays and just preparing now for a third Black Friday with them. We work with NASDAQ, so NASDAQ pretty much all price feeds at this point in time come through our system. We work with Answers at Microsoft.com, so all user queries that are going through Answers to Microsoft.com come through us. And that’s one of our large deployments that is across the board, four regions, multiple datacenters, active active. So pretty complex applications and pretty complex deployments.

    Alan Shimel:                Excellent. And Varun, when you engage customers of this size, where is the engagement coming from? Is it executive led or are there sort of technical champions that are bringing ScaleArc technology to the exec team?

    Varun Singh:               Sometimes it is executive led, sometimes it’s architecture led. Sometimes it’s even DBA or application developer led. It’s across the board. We’ve seen all kinds, but the most consistent one we’ve seen is the architecture, and that’s a pretty good fit I think with your show as well.

    Alan Shimel:                Yeah, yeah, I believe so.  So Varun, as I think we were speaking earlier, we live in interesting times. It’s sort of a boundary layer as we move into a world dominated by movements like DevOps and automation and continuous delivery integration, continuous integration, continuous everything. How has that played into your life and ScaleArc?

    Varun Singh:               It’s helping us massively. That’s pretty much exactly what people want. They want that application infrastructure to be continuously available. So from that perspective, the fact that databases are the last thing remaining in that stack which are hard to manage, we’re sort of flying at this point in time.

    Alan Shimel:                Exactly. So the database is one of the last pieces of the stack to kind of get the message about doing more faster and getting sort of a DevOps approach to things, or agile.

    Varun Singh:               Yep, and essentially what customers are right now aiming at is to be able to get to a point where they really understand their database stack and have full control over their database stack. And we’re kind of becoming that one control panel that they look at every day and essentially find out exactly what’s happening, whether it’s new users that are logging in to their database stack or new queries that are being executed that have never been executed before. And what we’re providing them is that entire stack as well as the ability to do zero downtime maintenance, being able to mark a server offline in the middle of the day, put a patch on it, upgrade it, and bring it back online. And you have never been able to do it in the past because you would have always had a ton of application errors, and what we’re doing essentially is eliminating all of those application errors and providing a transactional engine that works with pretty much any application engine and allows that application engine to become a zero downtime app.

    Alan Shimel:                Excellent. Varun, for executives listening in on here, what do you see as the next frontier or the next thing that CTOs, CIOs, VP, managers should be looking for in terms of database management, database performance, database load and so forth?

    Varun Singh:               I think at this point in time, they have to look at figuring out a way to expand out, scale out and get to what we call shared nothing. Shared nothing is essentially a way to store database information on servers in a way that you don’t have to worry about interdependency issues. So each server is its own individual isolated zone and even if you have five servers, you can have four of them go down and the fifth one will still be alive. So that’s the architecture that I think everybody is headed to right now. That’s the architecture that MySQL sort of made famous, and now at this point of time pretty much all databases are headed to that architecture. And databases are getting more and more sophisticated. But apps really haven’t been able to use that because the issue right now is that quite a lot of these apps are written to older versions of SQL databases. So what we do is provide all the new features that are coming in from the new databases to the apps without a single change on the app.

    Alan Shimel:                Excellent. Varun, we’re almost out of time here, believe it or not. We try to keep these chats relatively short. But a question I always ask people ending up is, for people listening in, whether they be managers, C-levels or people who want to be managers or C-levels. If you had to pick one book to read that would help them further their career and understand what’s happening and where they need to be, what would that book be?

    Varun Singh:               I could give you two or three right now, but if you really want one as far as an entrepreneur is concerned, I think The Hard Thing About Hard Things is really still the flavor of the month. It’s going pretty well still, I’ve sort of re-read it twice and it gives new meaning sometimes if you re-read it because you’re sort of analyzing a situation from a completely different perspective, and it’s a pretty interesting book to read.

    Alan Shimel:                So The Hard Thing About Hard Things.

    Varun Singh:               Yes, that’s by one of the partners from Jason Horowitz – Ben Horowitz.

    Alan Shimel:                Ben Horowitz, sure, I know the book well. Varun, and of course if people want to find out more about ScaleArc, is it ScaleArc.com?

    Varun Singh:               ScaleArc.com, and we’ve got a whole bunch of videos, we’ve got some webinars, we’ve got a lot of other stuff available as well as customer case studies as well.

    Alan Shimel:                Excellent. Varun Singh – founder/CTO of ScaleArc – thank you very much for appearing today on DEVOPS Chats and continued success with ScaleArc.

    Varun Singh:               Thank you. Thanks for having me.

  • To Be Continuous: Evolution of Continuous Delivery

    To Be Continuous: Evolution of Continuous Delivery

     

    In this segment of To Be Continuous, Edith Harbaugh and Paul Biggar discuss the evolution of continuous delivery. This podcast is brought to you by Heavybit, a 9-month program for developer startups.

    Edith Harbaugh, CEO LaunchDarkly

    Edith is CEO and cofounder of LaunchDarkly, a continuous delivery tool of “feature flags as a service.” LaunchDarkly powers software teams to quickly launch, measure and control their features.

     

    Paul Biggar, CEO CircleCIPaul is the CEO and founder of CircleCI, a continuous integration and deployment platform that automates development workflows and IT operations, allowing developers to ship quality software significantly faster.

     


    [soundcloud url=”https://api.soundcloud.com/tracks/224359194?secret_token=s-rlyTD” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]


    Edith: So Paul, where did continuous delivery come from?

    Paul: This is one of those things that evolved over quite a long time but I think that that major catalyst of continuous delivery was the fact that we moved to SasS and that SasS now exists.

    Edith: So what was it like before there was continuous delivery? What was it like when you were starting out?

    Paul: The first company that I really worked for was a games company and I think that a lot of them are kind of in the same place now. You would release software on a disk that shipped to customers via stores and you had to have a gold master at some point. We were a startup so it was quite advanced.

    We had a daily build server and we actually were selling middleware so we shipped software to those companies but those companies would ship at the end of the day, they would ship a disk that went out once and there was no updates at the time.

    It was 2003, 2004, something like that. There wasn’t any way to automatically update on customers’ Playstation 2, unlike even games now have a little bit of continuous delivery but back then, that was, you got your chance to ship it and that was it.

    Edith: Yeah, I just had a brutal flashback to one of my first summer jobs, which was installing Windows 3.1. This is back when you actually had a set of 35 disks so my job as a summer intern was to go to every computer in the office and just literally sit there. Disk in, disk out, disk in, disk out, and if something went wrong on the install, I had to start over at the beginning.

    It was a two hour long process just to get everybody up to 3.1 so in those days, there was no change of a fix pack. I think everybody was going to be on this version until probably they got another sucker summer intern in there.

    Paul: So if you imagine people and their, people installing, even modern or relatively recent version of Windows where you have to think about the service pack one or service pack two or what level are you patched to, that was basically the old way of doing software.

    The first time that I remember realizing that there was a different way to do it was in a Joel on Software blog. One of the major things that they could do is that there was a bug, they could fix it and in the cloud, it would be fixed.

    Edith:

    Yeah, I think it’s good though to realize that the reason that there was so much emphasis back then on making sure that a build was correct was because there was such heartache and pain if it was wrong.

    Paul: Yeah, it made sense to hold up the release for new features or for something like that if it was promised to a customer because then, there was no alternative. It would be three, or six or twelve months later when they got the next opportunity to go ahead.

    I think frankly, building software in the cloud and having the possibility of doing a release at any time you like has actually just completely revolutionized how people make software.

    Edith: I completely agree. So to go back to the old days, all the emphasis was on extremely high quality and extremely stable.

    Paul: Right, right.

    Edith: Because you basically had once chance. You were lobbing this thing out into the world.

    Paul: And even things where they had quarterly release cycles or something like that, it was still, it felt a lot like one chance. I worked at Mozilla and I was there on the switch from Firefox 3.0 to Firefox 4.0. Firefox 4.0 took 18 months to commit and there was things that were ready to be released the first week of that release cycle and that had to be held up for all these unrelated releases.

    I think there was problems with the JavaScript engine and there was memory bloat and that sort of thing that kept pushing it back. And Firefox, during the process, or during the time that I was there, switched its process and it switched to what they call a release train model where basically, they ship a new version every six weeks and it doesn’t matter what’s shipped or what’s not shipped.

    They’ll hold it up for total life, or build breaking, it just doesn’t work at all but basically everything else would make it go ahead. The cadence and the velocity that they’re able to get since that happened has been massive.

    Edith: Yeah, so that was the first evolution.  It used to be let’s try to cram everything in and then you’d get this vicious cycle where it’s like well let’s just put this one more thing in and then you’d have to add on all the QA time.

    Edith: So that was the other reason why releases would take so long is you had so much QA.

    Paul: Interesting.

    Edith: I talked yesterday to a guy who had worked at Microsoft and he said, you know, quality had to be rock solid for Microsoft going back to my disk example.

    Paul: Right, and these are people who have unit testing, automated tests as part of their builds.

    Edith: But even beyond that, you have to have a person actually try it and then you have to actually go out and try it on all these different systems.

    Paul: On all the different systems, right.

    Paul: So one of the things that made it possible for the browsers to do, to move to the release train model is that they had the alpha channel and the canary channel, or whatever it is they called it. In Firefox, it’s the Aurora channel.

    That’s the super, actually that’s not even the super beta stuff, they even have a nightly channel. They have a million people using the nightly and that tells them whether things are broken and how they are in fact and in production. I guess it’s kind of the first evolution of feature flags.

    Edith: Yeah, I mean let’s talk about that for a second.

    Paul: Right, we probably need to, aren’t we going to define things in this one?

    Edith: Yes, this is the definitional episode, Paul.

    Paul: Right, let’s start with what’s a feature flag because I think we’ve already talked about six things that we haven’t defined but what’s a feature flag?

    Edith: A feature flag is basically the ability to hide code but yet have it public. So it used to be that everything that shipped was visible. So a feature flag is just basically an if then that wraps a piece of code and says it might be shipped but nobody can see it until the software team decides that it’s visible.

    Paul: Right, and so some examples of that could be in a browser that you change a preference and the preference is use the new version of this or another example might be in, that a feature goes out in Facebook that’s shown to 1% of customers in Northern California who are in this demographic. Yeah, and it’s very liberating.

    Edith:

    The very liberating thing about a feature flag is that if something’s not working, you don’t have to do a redeploy.

    So to go back to the old dark days where you had all these disks out in the world, the feature flag is useless because you’re going to ship all these disks out to people and they’re going to install it. A feature flag is useful when people are consuming stuff as SaaS.

    Paul: The way that I think about a feature flag is that it separates the active shipping code from the act of actually turning on that code.

    Edith: Yeah, deployment from roll out.

    Paul: Right.

    Edith: Yeah, so it’s deployed, it’s available, but it’s not visible.

    Paul: Right, so now that we know what they are, what were we actually talking about?

    Edith: We’re working our way through the evolution of software so we got up to release trains. You should talk a little about how continuous integration fits into that.

    Paul: So continuous integration, to define it, it’s basically the act of having an automated build server that runs every day or at some sort of cadence and tests that your software works.

    So CircleCI, my company, makes continuous integration as a service and what happens there is whenever you push to GitHub, we’ll automatically check your code out, we’ll build it, we’ll run your tests on it, and we can also deploy it to your customers, which is called continuous deployment or continuous delivery, depending on exactly how you think about the world.

    Edith: You make this seem so simple but it’s really revolutionary. I remember the days without this.

    Paul: Sure, sure. I remember in my first job, we had a daily build server and so we would find out every day whether or not the code actually compiled, even though we could get it all compiling on our own machines or some modules of it or whatever, compiling on our own machines, there’d be all sorts of build artifacts and dirtiness in the code that meant that this code didn’t actually work when it was ready to be shipped to customers.

    Edith: Yeah, or even worse, I remember it used to be a thing when you broke the build, it was very shameful. You would have to sing a song or you’d have to do something embarrassing and that just doesn’t really happen anymore.

    Paul: Right, right. My co-founder used to forget to add new files to Git so it constantly wouldn’t work although it was perfectly working on his machine but there’d be a file missing somewhere.

    Edith: The classic excuse of, “Oh well it worked on my machine.”

    Paul: Exactly, yeah.

    Edith: Yeah, I didn’t know about builds my first summer job. At my first summer job, I was programming in Visual Basic.

    Paul: Okay.

    Edith: I was basically making a war game. It was for a defense contractor and I was trying to justify a space based laser versus an airplane based laser and if you had all these missiles coming over from Russia. Okay, this is a long time ago.

    Paul: Yeah, yeah.

    Edith: How many could you shoot down? The thing worked perfectly locally and then at the end of the summer, they wanted it off my machine. I was just like, “Oh.”

    Paul: Okay, you’d need to put it on a plane or in space or one of those things?

    Edith: No, they wanted my actual files off my machine.

    Paul: Right, yes, in order to put it in space or on a plane?

    Edith: No, it was just a simulation. I wasn’t actually controlling missiles when I was 19. Though that would have been cool.

    Paul: I had this absolutely terrible release process at this place that I worked. It was O2, which is a really large phone company in the UK, in Ireland, and I think they got bought by someone recently but whatever.  They were launching this feature called i-mode and i-mode is this massive thing in Japan that completely failed to take off anywhere else.

    Edith: Are you saying it was literally big in Japan?

    Paul: Literally, it was big in Japan. And so they tried to launch this in Ireland. Everybody in the whole world knew that this was going to be a failure, but that was how the process worked anyway. And the release process was they had all this code somewhere that was going to be deployed and attached in servers and when they did that, there’s a manual. I was part of the manual team that manually validated with handsets, clicking through handsets manually, and vouched that this stuff actually worked.

    There was no automation. The entire release process had to be repeated dozens and dozens of times as they fixed bugs and they reconfigured. It was, it was just a complete cluster.

    Paul:

    When I moved to doing software that had any sort of continuous release cycle, it was liberating because you actually know the path from what you’re doing on a day to day basis to it arriving at customers. Everyone, every developer in the place can know what that path is and everyone knows how code acutally gets shipped. You don’t have to keep it in a continuous state of you know, oh maybe one day I’ll ship this.

    Edith: Yeah, I mean I think to go back when you had these longer and longer and longer release trains or even pre-release train, people got very relaxed.

    Because it just was like oh, I’m just going to sit in the corner and code away and sometime in the distant future, it might ship.

    Paul: Right, and then as you’re coming towards the end of the quarter, everyone is hammering things out as quickly as possible and maybe there’s a few things that shipped early in the quarter that never got cleaned up or never got quite ready.

    Edith: What do you mean by shipped right now?

    Paul: So I remember sometimes where you’d merge something into master because you needed to get it tested but it wasn’t quite production ready. It’s out with the beta testers or something like that, but in order for it to actually ship to hundreds of millions of people, you need to remove whatever hacky thing you put in place.

    Edith:

    I think one of the things that has driven continuous delivery is just the rise of test-driven development.

    Paul: That’s interesting. Yes, I mean, I think it’s obvious. You end up in a situation where when you’re trying to move to continuous delivery, you’re saying I’m afraid and we talked about the fear last week.

    In order to get past that fear, you need to have automated testing and I guess in the old days, there was manual release cycles and you can’t do manual release cycles 10, 20 times a day. It’s just not possible.

    Edith: You can’t depend on having a fleet, like to go back to the Microsoft example, you can’t rely on having two QA engineers for every developer who will, you know, you just fling out code and they’ll find everything.

    Paul: Even with two QA developers, you can’t have two QA developers when you push code every five minutes.

    Edith: Yeah, they’ll never keep up.

    Paul: Exactly and then they’ll never identify the change that actually caused the bug and so on.

    Edith: Yeah, I think the things we’ve talked about so far, SaaS has unlocked continuous delivery, test-driven development has unlocked it. What else do you think is really a foundational thing?

    Paul: I guess the other one is kind of this change in customer expectations. Customers, as a fact of some people doing continuous delivery, everyone else has had to do it so once you start to experience it a little bit, and you start to wonder why do other sites go down for six hours on a Sunday night, this doesn’t make any sense. Why do I have to download new versions of this software versus clicking the update version or why do I even have to think about this?

    Edith: Yeah.

    Paul: I think for the installable software market or the desktop software market, Chrome was that sort of killer app that everyone sort of realized that this has completely changed the game.

    Edith: Yeah, it’s completely changed the game.

    I think even now asking people to download a plugin seems too onerous. They don’t want to do it. They just want stuff to work.

    Paul: It’s almost tied to a conversion funnel. If you expect people to install 31 disks to upgrade to the latest version of Windows, people are just not going to do it. You’re not going to achieve the conversion rate that you’re expecting. There is too many alternatives to your app that are out there.

    Thank you for listening, the entire Heavybit podcast can be found here.

  • 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 DevOps.com 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.

  • DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    DevOps Chat: Tyler Jewell, CEO, Codenvy why leaders need DevOps

    tyler jewellI had a chance to sit down with Tyler Jewell, CEO of Codenvy.  Tyler is an experienced tech exec and VC participant.  I met Tyler recently at the CloudBees CD Summit and Jenkins User Conference in Santa Clara. Tyler’s present company is Codenvy.  I spoke to Tyler about why and how leadership should engage DevOps.  Tyler says leaders need DevOps. You can listen below or read along. Enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/224505270?secret_token=s-gFEIj” params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Alan Shimel:                Hi, Alan Shimel, DevOps.com here for another Devops web chat on the Leadership Suite. Our guest today is Tyler Jewell who’s CEO of Codenvy. Tyler, welcome to Devops chat.

    Tyler Jewell:                Thanks for having me.

    Alan Shimel:                Tyler, I guess we should start off with those of our listeners who may not be familiar with yourself or Codenvy, why don’t you give us a quick background?

    Tyler Jewell:                I have been working at Enterprise Software for 25 years. I started off as a software engineer and then held a number of positions in product management at companies like BEA and Quest Software. The past six years I have been a venture capitalist, a partner at Toba Capital, investing in midware, Devops, and developer related technologies and while there at Toba Capital I founded and run Codenvy, which is now three years old.

    Alan Shimel:                Great. So another overnight success, huh?

    Tyler Jewell:                Business is good and there’s a lot more to be had.

    Alan Shimel:                So Tyler, for those of our listeners who may not be familiar with Codenvy, what are you guys doing over there?

    Tyler Jewell:                We are in the business of providing continuous development solutions, which is a part of Devops and continuous delivery. We do that by delivering on demand develop or work spaces that are easy to replicate, are constraint free, and collaborative.

    Alan Shimel:                Great. So Tyler, our audience for these chats are really managers, executors who are managing software – well, every companies a software company today, right? But these are people who are managing software departments and managing software delivery. Why should they care about what problems Codenvy is solving?

    Tyler Jewell:                Well, I think that there’s an interesting statistic that says 88 percent of organizations are now pursuing a Devops strategy and that’s just a phenomenal statistic in my mind considering that the term Devops did not appear before 2010. So in five years we have had essentially market saturation, and so why is that? And that’s the case because ultimately organizations that can release more frequently are able to drive customer happiness and this ceiling, this philosophy, has so many truths to it that software organizations are assessing their ability to deliver continuously at all stages of the pipeline.

    Where Codenvy fits into this is that we are providing continuous concepts to the pre-commit or the pre-merge phase of the pipeline, which is where the developers spends his time, and frankly where the developer spends a lot of their time configuring it and not coding.

    Alan Shimel:                Tyler, what about sort of system architects, system planners? Are they part of the Codenvy value chain as well, sort of even before the code, the proverbial papers taken into pen to paper, when we’re planning new apps and new software?

    Tyler Jewell:                Well, I think that historically the code has been the domain exclusively of the developer and there’s really no reason for that and that the code can become the domain of all audiences that are part of the software team, including the architect, but also the QA engineer, the product manager, the project manager as well. And essentially if you’ve been someone who has wanted to bill code or to run or debunk the code you needed to be a developer and set up a developer work space.

    That was a very technical skill set that you needed to have. In this day and age with the advent of containers and a lot of the automation that has been built into our technologies there is no reason that you need to be technical to recreate a developer environment. You can do that with URLs. You can do it online without installing software. And when you do you can allow users, your QA engineers, and product managers to get a feedback on to the code along with the engineers having these environments without overhead.

    Alan Shimel:                Got it. And Tyler, so we have this – to many people and especially to a lot of managers, execs, Devops is sort of developer led, but we’re also seeing this movement of IT ops, right? And as IT ops folks between to code more and infrastructure code starts happening more do you think we’ll see a migration from sort of Devops to IT ops being dominate here with this?

    Tyler Jewell:                Well, I think what we’re looking at is it’s a feedback driven initiative here. So whether it’s a developer or a development organization or an operations organization that is the driving initiative, the common goal here is to find ways to get feedback earlier into the life cycle. So whether that is an operation’s engineer or a developer it’s really about the people who value that feedback the most and can benefit from it.

    And feedback exists at every stage of the pipeline among all the different departments that are there and they all benefit from having that feedback as well. So I think they’re all gonna become drivers in their own way and they’re – any barriers that exist between them are gonna increasingly come down including perhaps their titles and job responsibilities as well.

    Alan Shimel:                Sure. Tyler, one of the functions of executives, especially IT executives, is we service somewhat of a translator between our very technical teams that we work with such as developers, such as IT ops or QA and even security. Between that group and then translate that into business speak for our peers who are perhaps CFOs or CEOs or nontechnical executives in the team. When we talk about the kinds of problems that Codenvy tackles, how can executives translate that into business speak that they’re CFO and CEO understands?

    Tyler Jewell:                Well, I think that if you are an organization that depends upon software either to be differentiated with your products out in the market place or to just be more efficient, the leap that CIOs need to make with their peers is that software teams that are high functioning are those that are able to release the most frequently here.

    So having a benchmark of release frequency, comparing that to your own ability, and then assessing your technological people in cultural capabilities along those lines is a simple way that you can start to communicate the benefit of having a very efficient software development organization that is embracing these technologies and philosophies. If that kind of assessment and narrative does not work then I think you have to take it back to perhaps manufacturing fundamentals, the theory of constraints here, which goes that if you want to produce a high volume, high quality parts, physical parts, you have to focus in on the portion of the work flow that is the slowest and most _____. And by resolving that and making that the most efficient then the entire manufacturing process becomes more efficient and software is the same philosophy. It’s just done with bits as opposed to screws and bolts.

    Alan Shimel:                Got it. Tyler, let me ask you to step back from your role as CEO of Codenvy for a second and put on your hat as someone as you said has 25 years’ experience in IT who’s served on the venture side of the house. What do you see as the biggest innovations or trends that executives should be watching around this whole new way of doing software and apps?

    Tyler Jewell:                Well, I think that they’re – as an investor at the very basic investment thesis in that the demand for software is increasing at a faster pace than the supply of engineers exist to produce it here. And so the only way to revolve this demand supply curve or this inequality that exists is that there’s gonna have to be tremendous innovations that show up that allow us to create software 10 or potentially even 100 times faster than we have in the past. And businesses and technologies that play to those trends are going to have outsized returns versus vendors who are not playing to those trends.

    So I think that’s the way I think about it and that’s abstract level. At a very concrete level the things that are playing to that, containers are absolutely fantastic. They provide low overhead. They also provide the programmatic definition of infrastructure which is something that we’ve never had before. So their rising adoption and popularity are a reflection of that. At the same time we’ve started to see new evolution of programming languages.

    Programming languages that are special purpose or domain specific are particularly geared towards Cloud development and those are making developers a ton more productive. And at the same time I also think that we’re continuing to see the rapid mobilization of knowledge workers around the world. We still have not seen a high penetration of that and there’s a lot more penetration to come. So those trends are inevitable trends that are playing into this Devops’ philosophy.

    Alan Shimel:                Got it. Last question, Tyler, and it’s the same one we ask everyone who appears on our show. For your executors out there, if they should read one book that will really help them with trampling with all of these kinds of issues and further their careers, what would you recommend?

    Tyler Jewell:                I’m a huge fan of Stephen O’Grady’s book that he wrote. It’s a two hour read. The title of that book – and this is my older age slipping my mind here – it is Developers are the New Kingmakers.

    Alan Shimel:                I know the book.

    Tyler Jewell:                It’s a fantastic read and I think that the book provides a very non-emotional explanation for why developers and development teams behave the way they do.

    Alan Shimel:                Yep. Excellent. Hey, Tyler, Tyler Jewell, CEO of Codenvy, thanks for being this week’s guest on Devops chats and much continued success with Codenvy and we hope to have you on again soon.

    Tyler Jewell:                I look forward to coming back. Thank you so much for having me today.

  • Open Source software license and security management with WhiteSource

    Open Source software license and security management with WhiteSource

    With the growing speed and availability of open source components, it becomes easy to add features and integration of software with other components which makes software development easier. But there are a few points to be remembered while using any open source component.

    • Security vulnerabilities
    • Licensing risks of open source component.
    • Outdated open source components.

    The above are a very important part of the the software development life cycle to eliminate any discrepancies related to security or legal issues.

    WhiteSource provides one fine platform to solve such issues without putting in much effort by developers, They can concentrate on core development instead of spending time on finding these issues which can be easily handled by WhiteSource.

    WhiteSource is an open source management solution which does

    • Open source licensing and compliance management
    • Open Source security vulnerabilities alerts and management
    • Executive dashboards, policy enforcement, and reporting

    WhiteSource checks your software and generates open source inventory report, including detail from open source. The WhiteSource gathers information on open source components and they keep the inventory updated.

    WhiteSource covers almost all commonly used languages and provide detail report, This tool can track all your open source components used knowing or unknowingly within your software.

    It sends alerts for any potential issue observed in open source component used by software. It does check for outdated/expired component, It provides detail on security issues found in any opensource component.

    WhiteSource does not store (keep track of) any software component which is not open source, this means it’s safe and your code will not be touched.

    CI tool Integration (Jenkins)

    The best part of the tool is that it has plugin available for the widely used CI tool – Jenkins.

    WhiteSource Jenkins plugin is the best and easy way to integrate with WhiteSource to run the checks during build and integration phase in an automatic way.

    Its very easy to use, not even just for Maven project also for free style projects.

    Easy to configure and use within project. Only token needs to be added and plugin automatically takes care of everything.

    Multiple options are available at job level to define the project and modules to be included.

    Logs are pretty descriptive when plugin start processing in Jenkins job.

    WhiteSource basic principle talks about

    Managing the component vs governing the component.

    Developers can leave the managing part up to WhiteSource and only concentrate on the issue of governance at the component level in software.

  • DevOps Leadership Series: Accelerating Adoption

    DevOps Leadership Series: Accelerating Adoption

    We are at an inflection point in the adoption of DevOps. Now is not the time to blink.

    DevOps was once thought to be a practice attainable by a select few.  The early pioneers were the ones with arrows in their backs.  For those who succeeded a new level of awesomeness was achieved and admiration was deserved.  But we have reached a new level of DevOps maturity today – one with broader participation across functional disciplines, where more rigorous processes being applied, and significantly more organizations are seeing a return on their early investments.

    This week, I caught up with three amazing guys with a wealth of DevOps experience to add to the DevOps Leadership Series.  We now have 18 free videos in the series.

    Dave Farley – DevOps for Everyone

    First, I sat down with Dave Farley (@DaveFarley77), co-author of Continuous Delivery.  Dave first talks about experimenting with and optimizing the development process from beginning to end, and then shares that DevOps is truly an approach available to everyone in the organization.

     

    https://youtu.be/1VLb3XQcRbA

     

    Brian Dawson – Cross-Functional DevOps

    I then sat down for a chat with Brian Dawson (@BrianVDawson), DevOps Evangelist at CloudBees, who is observing that cross-functional participation in DevOps is on the rise.  It is no longer a practice relegated to a select few participants in a development or operations team.  

     

    https://youtu.be/B2JhCMlYBDg

     

    Curtis Yanko – The ROI of Software Factories

    Finally, I caught up with Curtis Yanko (@onCommit), the former Architecture Manager for Cigna’s DevOps Center of Excellence (and now colleague of mine at Sonatype).  Curtis has been seeing the successful adoption of “software factories” reduce day-to-day burdens on DevOps teams which allows them to further accelerate learning and process improvements.

     

    https://youtu.be/Qv2wleI3TRAhttps://youtu.be/Qv2wleI3TRA

     

    On October 1st, we are going to extend these three conversations even further.  I have invited Dave, Brian, and Curtis to join me for a discussion on how to get started with DevOps or how you can reach the next level of maturity in your existing DevOps practice.  Be sure to sign up for this event – you won’t want to miss it.

    Screen Shot 2015-09-09 at 12.07.25 PM

     

    Dave, Brian, and Curtis will share 45 minutes with us discussing DevOps processes, adoption practices, technologies, and cross-functional alignment that are critical to DevOps success.  We’ll also share and discuss DevOps reference architectures that can jump start your own practice or further validate the path you are already on.  You can RSVP here.

     

  • The Women of DevOps

    The Women of DevOps

    No, this isn’t about some new calendar featuring scantily clad IT chicks. In fact the fact you even thought that is half the problem. This article arises out of the fact that I was speaking with a colleague the other day and once again had to regretfully recite that something like 95% of you reading this article are male (as well as every other article here).  Why is this? Why aren’t there more women in DevOps specifically and IT in general?

    Don’t get me wrong this is not a DevOps specific issue. We go through the same issue in the infosec realm as well. In spite of the fact that many trade mags in security have featured prominent woman in security and many security conferences have featured panels and discussions on this. The good news is slowly but surely this is starting to change. We are seeing more woman in the infosec world.

    So lets take that strategy from infosec and lets use it for DevOps.  Lets feature some prominent woman in the DevOps world.  I want to emphasize that these woman are here not just because they are woman and not men, but irregardless of their sex, they are remarkable people worthy of the recognition.

    Also before we get started, let me say that I compiled this list based upon people I have met, heard or read about. I don’t know all of these woman personally, though many of them I have met. Feel free to comment and add your favorites and choices.

    So here is my first list of the women of DevOps:

    1.

    bridgetBridget Kromhout is a Principal Technologist for Cloud Foundry at Pivotal. Her CS degree emphasis was in theory, but she now deals with the concrete (if ‘cloud’ can be considered tangible). After years in site reliability operations (most recently at DramaFever), she traded in oncall for more travel. A frequent speaker at tech conferences, she helps organize the AWS and devops meetups at home in Minneapolis, serves on the program committee for Velocity, and acts as a global core organizer for devopsdays. She podcasts at Arrested DevOps, occasionally blogs at bridgetkromhout.com, and is active in a Twitterverse near you.

    So that is the official bio (from her speaking appearance at Velocity). I only met Bridget in person recently but have been a fan for a long time. From her leadership in turning the DevOps Days MSP into one of the best in the world, to designing the DevOps against humanity cards and just the respect she gets from her peers in the DevOps community she is worthy to be the first person on this list.


    1. julie tsaiJulie Tsai,
      here is her official LinkedIn bio:Director of Engineering, Information Security for retail giant. Technical Operations leader and Systems Architect with proven decision-making and managerial ability. Experienced as CISO reporting to CEO, and concurrent Ops/IT head, for privately-held $100 mm Internet Advertising company with Fortune 1000 clients. IPO-readiness audit response; PCI,GLB compliance; SOX significant deficiency remediations; forensics experience. Ops due diligence representation; post-transaction department merging; deep budget cutting. Contract negotiation and budget optimization. Change management, incident management, uptime and DR/BC. Developed intuition for “what’s going to break next.”

    Notwithstanding the above, I couldn’t wait to add Julie Tsai to this list. She presented at our DevOps Connect: DevSecOps at RSA Conference last year (8 months pregnant and all) and just blew me away. She was so bright it was like a shining star up there on the stage. Her accomplishments speak for themselves. To me she represents the kind of person I would want my daughter or son for that matter to grow up and be professionally.

    3.
    helen
    Helen Beal
    , fanatical about making life on earth fantastic – with nearly 20 years’ experience working with companies to elicit real business value from software, Helen heads up the DevOps practice at Ranger4 focusing on how organisations can embrace DevOps philosophies to influence their IT culture and behaviours and implement tools for change. Helen is also a bibliophile and fond of llamas.

    The first person on this list that I also consider a personal friend, Helen has become a DevOps evangelist bar none over in the UK and beyond. She is constantly appearing, speaking and evangelizing on behalf of Ranger4 while organizations should adopt DevOps. She has also developed several DevOps workshops and lift offs.  If you get a chance you should catch Helen at a DevOps event near you.

    4.

    terri_potts1Terri Potts is an Engineering Fellow at Raytheon where she is the Information, Intelligence and Services Business Software Technical Director. She has worked at Raytheon since 1998 and has been an advocate and champion for modern software development methods since 1999. Her current professional interests include software and systems architecture, model driven software development, domain specific languages, software product lines, software factories and DevOps. Terri has been successful leading adoption of DevOps on Raytheon programs. Prior to working for Raytheon Company, she served eleven years in the United States Air Force in all phases of software acquisition and development of defense systems.

    Another speaker from last year DevOps Connect: DevSecOps at RSA Conference, she is also speaking at DOES next month. Terri is a dynamic individual who is spreading the DevOps gospel in the federal market and is smart enough to relate the story as a lesson for us all. Terri is a true leader, man or woman in the DevOps world.


    1. HeatHeatherMickmanher Mickman
      is the leader for the API and Integration team at Target and a DevOps enthusiast. Throughout her career, Heather has continuously embraced hard technology challenges from consulting large Fortune 50 companies on Supply Chain approach, implementing warehouse automation technologies, running large Ops & Support organizations, and establishing enterprise security approaches. She has a passion for technology, building high performing teams, driving a culture of innovation, and having fun along the way. Heather lives in Minneapolis with her 2 sons and 2 dachshunds.

    Taking the disaster that was Target IT and using it as a tool for transformational change via DevOps is worthy of all of our praise. If you get the chance to hear how Heather has helped lead this transformation (another DOES speaker) you should not miss it. Interesting note is how many large retailers have adopted DevOps successfully. Somewhat of a little known secret, but retail seems to be a prime vertical for DevOps adoption.

    6.
    Rosalind-Radcliffe1Rosalind Radcliffe is a Distinguished Engineer within the IBM. She is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi platform architecture. This includes z System and Power system. In addition she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM.

    Another person I have met in person and interviewed several times here on DevOps.com.  Rosalind’s CV is beyond impressive. Speaking with her though you know you are in the presence of intelligence.  I enjoy speaking with her and reading what she writes. She recently wrote Mobile to Mainframe DevOps for Dummies as well.  Rosalind is a real thought leader in every sense of the word.

    These are my first 6 women of DevOps. I will add to this list in the weeks ahead.