Tag: Consulting

  • Chronosphere Adds Professional Services to Jumpstart Observability

    Chronosphere Adds Professional Services to Jumpstart Observability

    Chronosphere has added a professional services capability through which it will provide the resources and expertise needed to deploy and manage its observability platform.

    Ian Smith, field CTO for Chronosphere, said the Chronosphere Quick Start program will make it easier for organizations to transition away from legacy monitoring tools that only track a set of pre-defined metrics and embrace an observability platform that enables DevOps teams to surface issues before an IT environment is disrupted.

    The scope of the services provided spans everything from data ingestion to providing training so that management of the Chronosphere observability platform can eventually be handed over to an internal DevOps team.

    The professional services team will also guide DevOps teams through setting up data control mechanisms and retention polices in addition to crafting dashboards to monitor specific processes.

    Finally, there’s also a self-paced online learning platform, dubbed Chronosphere University, that provides a comprehensive curriculum to help DevOps teams navigate fundamentals, advanced features and best practices.

    It’s still early days as far as the adoption of observability platforms is concerned. But it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary, but the biggest technical obstacles are deploying and configuring the platform, loading data and managing the cost of storing all the data that is collected.

    In addition, DevOps teams also need to understand what queries to launch to investigate specific issues. Many DevOps teams lack the expertise required to frame those queries today, but it’s expected that machine learning algorithms and other forms of artificial intelligence (AI) will automatically identify issues that might lead to disruption.

    In the meantime, DevOps teams should be evaluating where it makes sense to continue to rely on monitoring tools. In many instances, an observability platform might obviate the need for that tool, but there may also be plenty of instances where a simple monitoring tool is sufficient for the task at hand.

    One way or another, however, more advanced observability capabilities will be needed as application environments continue to become more complex in the cloud-native era. Application environments now consist of a mix of monolithic and microservices-based applications that gain more dependencies with each passing day. An application may not be as prone to crash as it once was, but determining the root cause of a performance issue can still take weeks given all the dependencies that exist between various services.

    Regardless of approach, observability has always been a core tenet of DevOps. As organizations’ DevOps maturity increases, the greater the appreciation for it becomes. The challenge has been that observability is one of many DevOps things that are easier said than done.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    M-Logic
    Dallas, Texas/Chicago, Illinois
    Security Engineering – DevOps
    $150,000 to $160,000

    SimplyHired

    Cisco Systems
    Waltham, Massachusetts
    DevOps Engineer
    $134,200 to $197,700

    Indeed.com

    AT&T
    McLean, Virginia
    DevOps/Python Specialist
    $111,000 to $140,000

    Monster.com

    Capgemini FS
    Charlotte, North Carolina
    AEM Full Stack Developer
    $110,000 to $130,000

    Dice.com

    Booz Allen Hamilton
    McLean, Virginia
    Lead DevOps Engineer
    $99,300 to $212,000

  • DevOps Chat: JFrog Expands Platform with Trainologic Acquisition

    DevOps Chat: JFrog Expands Platform with Trainologic Acquisition

    It’s always great to see companies in the DevOps space grow and expand their breadth of services. JFrog is the latest to fit that description. The company last week announced its acquisition of Trainologic, a Dev and DevOps technology consulting company, to expand its reach by helping new customers start their DevOps journey and supporting existing customers along the way.

    In this DevOps Chat, we speak with JFrog CEO and co-founder Shlomi Ben Haim and Gal Marda, founder and CEO of Trainologic, about the acquisition and how Trainologic fits into the JFrog vision of end-to-end continuous updates.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is around some big news coming out of our friends at JFrog, and I’m happy to be joined by my friend, Shlomi Ben Haim, CEO and co-founder of JFrog. Shlomi, welcome.

    Shlomi Ben Haim: Hey, Alan. Thank you for having us.

    Shimel: Thank you. And joining Shlomi is a new member of the JFrog family, Gal Marda, who is the, I guess, founder and CEO of—or was the founder and CEO of Trainologic, correct?

    Gal Marda: Correct. Great to be here. Thanks, Alan.

    Shimel: Welcome, and welcome to the JFrog family.

    Marda: Thanks a lot. It’s very exciting for me.

    Shimel: So, I’m gonna let—Gal, I’m gonna let you tell our audience the big news coming out today. What went down here?

    Marda: So, what went down, as Alan said, it’s very exciting, actually. Shlomi had this great idea of JFrog coming out with this platform, the EPlus platform, which is a complete revolution in the DevOps industry, in my opinion, and he thought that DevOps and the vision of liquid software, to make it successful, it’s both tools and practices. And taking out this platform and making sure it’s successful requires some consulting services as well to make sure that JFrog customers are making the right decision on the way they used the Enterprise platform.

    So, the idea was to join forces together and bring us on to make sure the customers are being successful with the use of the Enterprise Plus platform.

    Shimel: Excellent. So, Shlomi, let me ask you—JFrog as a company has had tremendous success, tremendous growth. Last year, you moved, really, to a platform type of solution in the marketplace, right, offering the platform. Why Trainologic, why now?

    Ben Haim: That’s a great question, Alan. So, as you know, and we spoke about it in the past, the real pain that DevOps is here to solve is not about the milestones of continuous integration and continuous deployment and continuous delivery and continuous testing. These are all very important milestones that created and ________ revolution.

    But, basically, if we will all have a solution that helps us to get to a place that we have continuous updates, that software is being released fast and secure, then the DevOps evolution would be at the procurement level. What we released this year, the Enterprise Plus, is a bundle of seven different products, and it’s not any more one product that you install and run at the server side, then serve your developers. It’s more than that. It’s an end to end binary solution.

    And what we figured out is that we need some experts to help us with the adoption and the know-how and the knowledge transfer among our users. So, we have 4,500 Enterprise customers today. We need Gal’s team to work with us in the field, on customer sites to support that goal.

    Shimel: I wholeheartedly agree, Shlomi. You know, I’m reminded of, back in my days at Interliant, where we did early cloud hosting—things like Lotus Notes and PeopleSoft and Oracle applications. And what we discovered then was, you can never take a sophisticated application like that out of a box, plug it in, and say it’s gonna work, right? There was always, at best, 75 percent, it worked. You always needed professional services, 25 percent, to come in, customize it, fine-tune it, make it work.

    And, really, that—you know, even in the security space, so many of the most successful security companies, when you look at their revenue breakdown, it was the professional services, because security is hard. And people just can’t do it, and so, to me, anyway, there’s no surprise that this is a DevOps problem as well is that you still need those experts to come in and do it.

    My question to you is, though, is that, as a CEO in your position, you’re always—you’re gonna need to balance how many bodies do I want, right? How do we scale this? Because it’s a body intensive, it’s a people intensive business model.

    And so, you know, what—and Gal, you may have experience, having led the charge at Trainologic. What do you do there? How do you keep it in check?

    Marda: So, I—Shlomi, are you taking this, or me?

    Shimel: Either of you.

    Ben Haim: Yeah, I’ll speak about the ratio, and Gal, you will speak about the best practices coming from your experience. I think, Alan, you are right. When you come with—it’s not just the technology, it’s not just the new things that are happening in the market. And the DevOps market is booming. You see it from everywhere, from fundraising to technology adoption, new things, innovation, every morning we are waking up to some DevOps news. So, this is a very exciting day for companies like JFrog.

    But what you also see is that a lot of companies are starting to onboard giant organizations, thousands of developers to a new methodology and new tools. Therefore, we have to keep the balance between what we release to the market and how it’s being adopted. Because otherwise, we will overwhelm our users with technology that nobody understands how to use, and they will—you know, the first reaction will be a reflex reaction of just dropping it and have this mantra of what works should be, stay as it is. If we want to keep innovation, if we—sorry, to push innovation—if we want to keep the market momentum, then we also have to support the market with the onboarding. This is one thing.

    The second thing—JFrog is a product company. JFrog is not a service company. But building the product without helping our customers to better use them is meaningless. It’s just like having a great technology with the wrong execution. So, we are looking up to companies in our field that did this stuff two years ago, three years ago, and how the market adopted their platform. And we learned a lot from it, we did the analysis. So, when we reached out to Trainer Logic and asked Gal to join the team to the swamp, basically, the first thing that we looked at is, is this company already installing ________ Factory and Xray and Bitray and the JFrog pool? Second, is it a big enough team? It’s a TS Super Command Unit, so not too big, and if Gal and the team will be able to build a community, not just with the JFrog professional services, but also with the community of professional service companies around us, and to be some kind of a business development within these units around the world to help us spread the JFrog technology.

    Shimel: Excellent. Gal, do you want to add to that?

    Marda: Yeah, sure. So, you asked about scaling, so I think Shlomi has it correctly. We are going to be a relatively lean and mean command force. We’re not gonna be like thousands of people, but we’re, we can scale in several ways. One of them is, as Shlomi mentioned, by partnerships, okay? We tend to create a network of partners and a community that will help us work together. We’re not going to deal with it all by ourselves.

    And, in terms of scaling inside and taking people and training them, that’s something that we’re very used to doing. We are making sure that young people are shadowing, and we’re grooming them, and we’re teaching them a lot more of our practices, and we’re making sure that they see a lot of different architecture and a lot of different customers with different ways of thinking. And with this kind of activity, they become very experienced in a relatively short time because they see a lot of stuff, and if you take talented people, you give them the right mentoring, you let them see a lot of different solutions and approaches, they become very efficient in a relatively short period of time.

    Shimel: Excellent. So, is this, the commando teams going in and stuff, Gal, do you envision them—so, is every job a one-off, or is there a sort of standardized package that you’ll develop for most customers?

    Marda: Well, it’s still in the making, but I am—we are planning to create some packages, because during our experience in last year’s meeting, a lot of different companies and providing them with different services, we realize that there are the same needs that are returning again and again.

    One of them, for example, would be some kind of DevOps analysis, like a gap analysis of where you should be or where you want to be, and what’s your current DevOps state? So, for sure, there will be different types of packages, and inside those packages, of course, a lot of the work will be tailor made because every company is different, and as you know, DevOps is also very culture related and related to many other things in the company. So, for sure, it can’t be the exact same thing that will be provided, but the general framework in the packages will be, different packages will offer off the shelf.

    Shimel: Excellent. So, Shlomi, Gal said the magic word—culture. How does this—you’ve done other acquisitions. You’ve acquired JFrog China, I saw awhile I was in China, I saw them at an event. Some other acquisitions you’ve done over the years. But those were kinda product related companies; this is clearly a service one. How does that—I mean, you have a great culture at JFrog, right? I’ve witnessed it firsthand. It’s admirable. How do you make—

    Ben Haim: Thank you.

    Shimel: – ________ Froggers in the swamp?

    Ben Haim: Well, first of all, thank you, Alan. You know, we acquired four different companies, from Conan with the C++ package manager for DevOps and then CloudMunch, that becomes the JFrog Insight product. And then DMon and now Crenologic, and the one thing, one rule of ________ is the fact that you always, you should always seek for the combination between the strategy and the culture.

    And, the first time that I met Gal, under the idea of the acquisition was at swampUP, in our user conference. So, for me, there is no better place to bring someone and show him JFrog, not just from a technology point of view and a product point of view, but also community relations and also the Frog vibe and the Frog DNA.

    And then, when we started the discussion between us, actually, the two groups that worked hard on this deal were the HR group and the Operations group. And the first thing that we shared with Gal was the JFrog products. So, I think that Gal wouldn’t join JFrog if he would feel that this is not the right fit on the cultural point of view, and the strategy moving forward can be something that will change the world of the Enterprise culture.

    So, the liquid software vision, together with the JFrog culture, I think kind of blended into what Gal believed in and what his team already is doing for the past 10 years. And what we have seen there was an identical picture of JFrog. It was almost like a glove to a hand, and now, after we signed and they are part of JFrog, I can say that this was a love story from the first moment we met.

    Shimel: Alright, and it was a happy ending. [Laughter] So, I have to ask you, Shlomi—so, now, you’ve acquired a services company, Commandos, what’s next? What’s next at JFrog?

    Ben Haim: That’s a perfect question. Actually, you sound like my ________ now. [Laughter] So, on the service level, I think that what Gal and Tali, our VP of Worldwide Sales, are working on now is how to merge these capabilities now with the Enterprise class, the JFrog class from adoption. This is one thing.

    The second thing for JFrog is the extension of our technology. We see the consolidation in the DevOps market happening. There is two buckets that consolidate all the technology. One of them is the code repository, so you see what happened with GitHub and Bitbucket and so on. And the other one is the artifact repository. So, those two buckets are kind of consolidating all the technologies into it, and we are looking at it and we are looking at the landscape, and with the universal solution we provide and with the hybrid solution we provide and with the freedom of choice philosophy to be a developers first and DevOps first company, we will extend the technology.

    So, stay tuned. I promise you that, at the beginning of 2019, we will have more news about technologies that support our goal.

    Shimel: Fantastic. Gal, I’m gonna give you the last word.

    Marda: Okay. Thanks for that, first. I must relate to what Shlomi said about love at first sight and the culture. It was amazing to see. When Shlomi called me, first of all, I was very flattered and surprised. But what I’ve realized very fast is that it’s kind of where we’re seeing the same thing but we were trying to help our customers in different ways. JFrog was doing that with creating great technology, and we were doing that with providing them with the best services we could.

    But we tried to reach the exact same goal, the exact same way—developer first, technology first, and while we appreciate and we are all people persons and see the people and try to say, to maintain a very special culture. So, I think that’s a great fit in that matter, and I think it’s the most important one. So, I totally thank Shlomi for this opportunity to be part of JFrog, and I feel that we’re very much alike to begin with, but it’s a great honor to join a company like JFrog.

    Shimel: Well, congratulations.

    Ben Haim: Alan Shimel? Alan?

    Shimel: Yes, Shlomi?

    Ben Haim: You saw JFrog growing, and I’m very—you know, I’m very excited to have this conversation with you, because it’s like seeing different generations in JFrog. We will make the world of software liquid. We will liquefy software. This is our vision, so stay with us, I promise you we will have more news for you.

    Shimel: I’m not going anywhere, and I have every confidence in you.

    Ben Haim: [Laughter]

    Shimel: Gal, to you, as they say in Boca Raton, Mazel Tov.

    Marda: To dava. [Laughter]

    Shimel: [Laughter] Alright. Shlomi Ben Haim, Gal Marda, JFrog—congratulations, good luck. We’ll check in early in 2019. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • REP SPOTLIGHT: getITright

    REP SPOTLIGHT: getITright

    DevOps Institute: Tell us a little about your organization.

    getITright: With offices in Australia, South Africa, The Netherlands, Nigeria and Malta and a network of partners operating in 31 countries, we offer a bouquet of services to help organizations to:

    • Manage better
    • Lower risk
    • Perform better
    • Make better business and IT decisions

    Our service offering includes:

    • Training courses – Learning best-practice through our Partner Academy courses or network of training providers
    • Accredited IT Best practice course material – License our training material
    • Consulting – We use an agile approach for projects and a lean approach for operations when consulting and coaching.

    DevOps Institute: What other topics do you teach or consult on?

    getITright:

    • Service Management: ITIL®, ISO/IEC20000, Lean IT, Service Desk Institute
    • Governance of Enterprise IT: COBIT® 5
    • Project Management: PRINCE2®, PRINCE2® Agile, DSDM AgilePM®, Scrum
    • Information & Cyber Security Management: ISO/IEC27001, NIST Cybersecurity using COBIT5
    • Quality Management & Business Improvement: ISO9001, LEAN SIX-SIGMA
    • Risk & Continuity Management: ISO31000, ISO/IEC27005, ISO22301
    • Cloud Computing

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    getITright: DevOps awareness in the region is still low, but we see a steady increase in the level of interest in the topic.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    getITright: It makes projects and business as usual faster, more stable, with less risk.

    DevOps Institute: What topic area in DevOps excites you the most?

    getITright: DevOps enables organizations to improve productivity and respond to change with less risk. It’s easy to adopt by organizations with mature ITSM practices in place.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    getITright: Training ensures that all resources in the organization are in sync when implementing new practices like DevOps in an organization and ensures a cohesive approach that facilitates proper organizational buy-in and adoption.

  • The perfect fit: what to look for when hiring a consultancy group and how to build a lasting relationship

    The perfect fit: what to look for when hiring a consultancy group and how to build a lasting relationship

    Whether your company is just getting started or has been in business for years, selecting and building the right team makes a significant impact on your output quality, team morale and retention. If you are looking for engineers that are skilled, experienced, and a good cultural fit to step into a new or ongoing technology project, consider hiring a consulting group.

    Once you’ve determined that a consultancy group is the right solution for your business, you will need to select a company to work with. But what should you look for when hiring a consultancy group? Make sure you’re choosing the team that is perfect for your company, and how should you manage them once you’ve started working together? A selective, thorough approach to hiring and managing a team will result in exponential benefits for both your product development and overall team morale.

    Hiring the Right Team

    Look for a dynamic, adaptable and nimble team. While the specs for your project may focus on one aspect today, the next day you may discover the need to pivot in an entirely new direction. Engineers need to understand programming principles and paradigms before being proficient in any language, so make sure that the consultancy group you select has engineers that are skilled enough to easily switch languages and architectures, learn new languages and migrate to different environments, among other things.

    Assess candidates holistically.When looking for the best-fit consultancy firm, be sure to evaluate both their technical and soft skills. Carefully assess their technical abilities and make sure that the skills and experience are there. Be sure to also evaluate their soft skills such as attitude, energy, cultural fit, personality, motivation and ethics. If you cannot meet the team you will be working with in-person, try video-conferencing to get to know them face-to-face, which can help with making sure it will be a fit. Lastly, take the time to look into the consultancy group’s track record of success and what current and past clients have said about their work.

    Setting Your New Team Up for Success

    Prior to beginning the engagement with the consultancy group, be sure to communicate expectations clearly and eliminate as many questions as possible to avoid mistakes and multiple iterations. It can also be very helpful to provide your consultant with a thorough “Requirements” document, wireframes and as much context as possible to help them get up to speed as quickly as possible.

    Motivation is also key with any successful software development team and can make or break a project. Make sure that everyone understands and believes in your vision before embarking on a new project. For a longer-term project, consider switching team members between projects and technologies to allow them the opportunity work on something new and keep them engaged in their work.

    For teams working remotely in various locations, managers should provide honest, regular and respectful communication with their remote teams to build camaraderie, trust and overall passion for the project. Get the most from your team by leveraging any differences that exist, they may turn out to be your greatest advantage in the end!

    Managing your Team 

    As a manager, it is important to create an environment that allows your engineers to focus on what they do best: building software. Be sure to communicate frequently with the remote teams to answer any questions they may have during the project lifecycle and keep it on track. Use a cooperation platform or Project Management platform to organize and track the technical details of your project. Establish any parameters to work around early on and as your project progresses always communicate any changes in the desired outcomes.

    Make sure to embrace your consultants as an extension of your team. If you don’t, there will be disconnect between the teams and the relationship will not work out. Trust is also incredibly important. Consultants are highly skilled and should be able to handle projects you give to them. Also, contrary to popular belief, all consultants aren’t “yes men” and can have great suggestions for how to streamline projects or tweak certain aspects. Keep an open mind and consider what they have to say!

    The process of hiring a consulting firm may seem daunting at first, but taking the time to know what to look for will streamline the process and help you recognize what is most important when building your team. Once you select a firm, trust and open communication between your company and your new team is key. Closely integrating the two teams and fostering mutual respect between them both will help you on your way to building strong, lasting relationships and successful projects.

    About the Author/Theo Nissim

    Theo headshotTheo Nissim, CEO at Gemini Solutions, Theo is a seasoned Silicon Valley technology executive with more than 20 years of experience. He has led pre-IPO start-ups, built dozens of technical teams, developed technology strategies and driven innovative products and solutions to market. One of Theo’s many strengths and passions is managing large scale, cross-functional development efforts to high profile product releases. Theo has held executive and management positions with large public companies, Sun Microsystems and Wind River Systems, and served as the Engineering Vice President for VC funded start-ups, Digital Fountain and AdKnowledge.

    Theo has a Masters Degree in Computer Engineering from the Technion, Israeli Institute of Technology in Haifa Israel. He lives in Palo Alto, California, with his wife and twin boys

  • Step One Of DevOps Ignores Technology

    Step One Of DevOps Ignores Technology

    I’ve spent a bunch of time talking with Adrian Cockcroft, former cloud tzar at Neflix, and listening to his various talks and presentations. I’ve also spent a bunch of time looking around the various rooms within which he presents and seen the dazed look of attendees who have rightly assumed that just seen a picture of the way organizations should be. Netflix is unquestionably an exemplar for IT reinvented – where innovation, agility and developer enablement are natural parts of what they do.

    But then I’ve seen these new disciples of the “Netflix way” write a list of the technologies that Cockcroft detailed and attempt to shoehorn those same approaches into their own organization. All to often the result is disappointment, failed projects and a swing back to the traditional rigid ways of doing things.

    These thoughts struck me then I hear about this new masthead and its aim of creating a hub for DevLops thought leaders – surely giving IT practitioners a good place to find the latest tools and techniques will help spread the DevOps gospel?

    Well yes, and no. You see I’m a firm believer in the viewpoint that DevOps has very little to do with products, processes and policies, and instead is a direct result of a particular type of culture. On the one hand you have Netflix, clearly a cultural outlier with its openness, willingness to experiment, embracing of failure-driven iteration and aim of planning for failure. On the other hand you have traditional IT shops that are top-down, driven by a rigid policy framework and consider the “operations department” and the “developer team” as two distinct entities.

    This was a topic that Christian Reilly (he of the sartorial elegance and funny accent tendencies) and I discussed a couple of years ago, before the DevOps hype had really started to hit. In the video, he reflected directly on his organization, Bechtel, as an outlier at one end of the spectrum, while Netflix is an outlier at the other. It’s a somewhat dated video, and talks about public/private cloud, but the themes in terms of organizational readiness hold true for DevOps as well.

    [youtube http://www.youtube.com/watch?v=gVG1Pj4cW-g&hd=1]

    So my aim in my regularly irregular DevOps column in here is to talk about everything but the technology. And where better to start that the first step towards DevOps which is, I believe, all about building cultural bridges rather than making technology choices. It should be a natural concluding that, since DevOps is all about bridging the developer/operations span, that perhaps getting people in a room to talk about their particular drivers and metrics would be a good idea. But alas most people go from talking about DevOps to deploying their choice of automation tool.

    There’s so many things to think about in embarking on this process – over on the ScriptRock blog Alan points out that visibility is a key first step before automation is embarked upon. While I agree with him that visibility is key, for me the money quote comes in his post where he writes:

    Don’t automate what you don’t understand

    But to then suggest that the first step should instead be a visibility tool does little to improve the outcomes – unless both sides fo the organizational divide are in the same room and accepting a common lingua franca and viewpoint on the data – visibility achieves little. So takeaway #1 focus on the culture. There’s lots of ways to build the bridges needed to change the way an organization looks – I’m going to cover some of that stuff over time.