Tag: devopsy.kinsta.cloud

  • Deeper Technical Information with SweetCode and Fixate

    Deeper Technical Information with SweetCode and Fixate

    I know many of you go right to the article you want to read on devopsy.kinsta.cloud without ever visiting the front page. But if you go to the home page and look down in the bottom right corner of the page, you will see a link to Sweetcode.io. Sweetcode is a site run by Chris Riley and the folks over at Fixate.io, offering great deep, technical articles on all things DevOps and more. Check it out.

    More importantly, it is the visual evidence of a deeper strategic partnership that we here at MediaOps have formed with Fixate. I have known Chris Riley, the founder of Fixate, for about five years now. Chris has done a great job of developing a deep bench of technical writers who can really deliver the technical viewpoint without the marketing fluff. I know this is exactly the kind of content our audience loves. Not just our reading audience, either—our sponsors are also challenged to create good technical articles for their audiences. Now, we can deliver this either to our sponsors or on behalf of sponsors.

    On top of this, we are also going to add Chris’s technical chops and talent to our roster. You will see him hosting webinars, doing interviews at conferences for Digital Anarchist and otherwise engaged with our audience. Chris brings a practitioner/analyst viewpoint to his work that I think our audience will appreciate.

    I should emphasize this is not an announcement of an acquisition or merger with Fixate. Fixate will continue to operate as an independent company (which it is). We will just be working really closely with Chris and team there to help bring you deep technical articles and other forms of content that we believe you will find interesting. It is all part of our plan to keep creating and distributing the kind of material that our audience is looking for.

    So, go check out Sweetcode. We also will be promoting Sweetcode through our social media and newsletter channels. Stay tuned as we turn up the gas, and we hope you enjoy.

    — Alan Shimel

  • MediaOps, Inc. Expands Executive Leadership Team to Drive Growth and Audience Reach

    Producer of devopsy.kinsta.cloud and other Premier Tech Communities Capitalizes on Rapid Growth of Cloud, DevOps, and DevSecOps

    Boca Raton, FL, (June 13, 2017) – MediaOps, Inc., producer of leading technology brands and destinations such as devopsy.kinsta.cloud, DevOps Connect, DevOpsTV, DevOps Chat and Container Journal, today announced the appointment of two executives to the company. Joining MediaOps are Saleem Padani as Chief Operating Officer, and Deborah Schalm as Director of Marketing Operations and Customer Delivery. The appointments strengthen MediaOps’ leadership as the company scales to expand the rapid growth of its supporting communities.

    “We believe that MediaOps has a great opportunity to expand its audience, influence, and reach due to the ascendency of emerging technologies and disruption in the traditional tech media industry. Saleem and Deb bring technical and marketing expertise to their positions and the company,” said Alan Shimel, CEO of MediaOps. “These talented individuals, both with great track records of success, will enable us to further drive audience engagement and provide seamless user experience across all our digital properties.”

    Saleem Padani

    Mr. Padani joins MediaOps from IBM, where he managed worldwide DevOps portfolio marketing with a focus on hybrid cloud, methodologies, security, enterprise systems and C-suite conversations for specific industries. He managed relationships with internal and external media outlets as well as clients and business partners, led social media strategy, events, and content marketing in support of broad marketing campaigns. As a tech industry veteran, Mr. Padani’s background includes prior roles as co-founder, software engineer, architect, and consultant with early-stage technology companies.

    Deborah Schalm

    Ms. Schalm has an extensive background in media and marketing having served in marketing positions at Time Inc., Hearst, Wall Street Journal Office Network, Inc. Magazine, and others. She brings valuable expertise in integrated marketing, sales development, client management, and marketing operations. She will manage several areas of delivery including digital marketing initiatives, digital libraries, and webinars, working with MediaOps advertisers to deliver valuable, educational and compelling integrated content to its audience.

    About MediaOps, Inc.

    MediaOps is a premier global media platform for technical communities including DevOps, Security and Containerization. Its brands, which include devopsy.kinsta.cloud, DevOps Connect, DevOpsTV, DevOps Chat and ContainerJournal.com, attract and engage a thriving online community of technology professionals around the world. Resources include award-winning editorial, creation of high quality custom content supporting all stages of the buyer’s journey, from awareness to decision, multi-media production and distribution. As the leader in these emerging segments, MediaOps’ properties include powerful, integrated marketing and communication platforms to help clients maximize their campaign ROI and paid media investments.

    For more information, visit devopsy.kinsta.cloud.

    ###

    If you would like more information, please contact Deb Schalm at 203-979-9412 or email deb@devops.com.

     

  • DBmaestro Named Best New DevOps Solutions Company by devopsy.kinsta.cloud

    Company recognized for pioneering enablement of DevOps for databases

    Boston MA, February 13, 2017 – DBmaestro, the pioneer and leading DevOps for database solution provider, was lauded for “standing out from the crowd” in the 2016 DevOps Dozen Awards. The voting was conducted by devopsy.kinsta.cloud and consisted of thousands of people in the industry who casted their votes in 12 categories.

    According to the publication, DBmaestro is “pioneering the DevOps for the database market. DBmaestro has gained attention not just with a great product/service, but also by producing high quality content to help evangelize and educate the DBA market about DevOps.”

    As to the future, devopsy.kinsta.cloud has lofty expectations for DBmaestro. “We expect big things from DBmaestro going forward. Can’t wait to see what they do for an encore.”

    “The DevOps Dozen is meant to acknowledge the leaders, movers, shakers and innovators in the DevOps community,” wrote Alan Shimel, Editor-in-Chief of devopsy.kinsta.cloud. “With so many great companies and people involved in the DevOps world today, it is really hard to pick the very best. Congratulations to all who won these incredibly close races.”

    “To have been named alongside Jenkins, Automic, Chef, IBM and others as a winner of the prestigious DevOps Dozen is a huge validation of everything we’ve accomplished,” said Yariv Tabac, Co-Founder and CEO of DBmaestro. “Early on, DBmaestro’s solution was strongly adopted by Global 2000 organizations, specifically among the financial and healthcare sector. More recently, awareness of database DevOps has increased and we see widespread interest from medium size companies as well. Database DevOps will continue to grow, and we are committed to remaining at the forefront of the industry.”

    “The importance of enabling the database within a DevOps framework is increasingly understood by technical leaders,” said Co-Founder and CTO Yaniv Yehuda. “There is a strong need to automate the continuous delivery and integration process in order to accelerate time to market and ship high quality applications safely. DBmaestro is the only solution which addresses the three critical pillars of database DevOps readiness: agile database development, database release automation and process control (security, compliance and policy enforcement).

    About DBmaestro

    DBmaestro is the leading automation and DevOps for database solution provider. Its flagship product, TeamWork, enables Agile development and continuous integration and delivery for databases.

    DBmaestro TeamWork enables collaborative database development, enforced source control, release, and deployment automation. Thus, significantly reducing the risk of costly downtime, cutting release automation costs by 80% and boosting development productivity by 15%.

    Major enterprises in industries such as financial, healthcare and retail have already chosen DBmaestro as their database automation solution.

    — Charlene O’Hanlon

  • Addressing Container Security Challenges

    Addressing Container Security Challenges

    From month to month or even week to week, more organizations are developing with containers. The concept of containers isn’t all that new, but the dramatic rise in adoption of container technologies and the support from major tech vendors and platforms has helped containers become mainstream quickly. As with most emerging technologies, now that containers are hot there is a greater focus on some of the security issues of containers. So devopsy.kinsta.cloud worked with leading vendors to address that issue.

    A new report from devopsy.kinsta.cloud, sponsored by Aqua Security and Microsoft, examines the weaknesses of containers and that the security concerns introduced by using containers, and provides a look at some of the approaches to addressing those issues. “Containers: Security Challenges and How to Address Them” contains insights from DevOps and containers experts to help you understand the challenges and how to solve them.

    The report explains, “There is a general lack of awareness of existing container security concerns and best practices. Organizations need to understand the security issues that arise due to the differences in how VMs and containers function. Enterprises need to prepare for the glut of additional files that need protection with containers and the unwieldy nature of third-party libraries that containers use. Businesses also must consider configuration mistakes including those that grant root status to containers or simply make containers overly complex. Most importantly, organizations that adopt containers need to accept responsibility for security them, and should expect to keep tabs on new container vulnerabilities as the industry discovers them.”

    “Containers add a layer of obscurity that reduces visibility,” warns Amir Jerbi, CTO of Aqua Security. “You have an operating system running a container engine, which in turn runs containers. The OS is not aware what containers are running—it only sees the container engine. The container engine knows what containers are running, but has no clue what the containers are actually doing. So, if you’re running a host-based security tool to monitor the OS, you will not see what containers are running and what they’re doing.”

    Thankfully, there are solutions and best practices you can employ. The report describes how to use a combination of preventive measures, active detection and active response to protect container environments. It also covers some of the approaches to creating a more secure container in the first place using concepts such as isolating the containers with virtualization, as Microsoft does with Hyper-V Containers.

    “What’s really important about Hyper-V Containers is that rather than trying to close existing holes, now we can implement a solution that is secure by default and already meets compliance requirements,” explains Taylor Brown, principal lead program manager at Microsoft.

    You can download the free report from devopsy.kinsta.cloud by clicking here: “Containers: Security Challenges and How to Address Them.”

    — Tony Bradley

  • DevOps Leadership Series: Security at Velocity

    DevOps Leadership Series: Security at Velocity

    If it does not fit, it does not get done.  For many DevOps practices, application security falls into the “does not get done” bucket.  That’s because for many DevOps-centric organizations, application security has historically been done somewhere else, by someone else, who is slow.

    Go faster.  Shift left.  Remove complexity. Reduce rework.  All mantras of DevOps practices.  And while DevOps practices have changed dramatically in recent years, many experts will tell you that application security has not changed enough.

    In this installment of the DevOps Leadership Series, you will hear Chris Corriere (DevOps Engineer, Autotrader) and Mitchell Ashley (VP Information Technology, CableLabs) share perspectives on the state of DevOps and security. It is about security at velocity.

    But is going faster and automating resulting in better security? There are still security pros who are uncomfortable with that premise. Nevertheless, that is where this is headed. The security community has to come to the mountain, otherwise the mountain is coming to them.

    First, listen to Chris’ Corriere of Autotrader tell us his perspective that security can move at DevOps speed, as long as you take a diversified approach:

    https://youtu.be/8DdfHkAK1Fk

     

    Then hear from Mitchell Ashley, VP of IT at CableLabs as he remarks on the evolution of security from a validation role (at the right) to an integrated, ingrained role that has shifted left:

    https://www.youtube.com/watch?v=pg_m7dYqUPU

    This is the third in our series of interviews from this event. Stay tuned as the actual sessions from DevOps Connect will be posted shortly.

    NOTE: If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).

  • Happy Birthday devopsy.kinsta.cloud and what a year it’s been

    Happy Birthday devopsy.kinsta.cloud and what a year it’s been

    They say it’s your birthday
    We’re gonna have a good time,
    I’m glad it’s your birthday
    Happy birthday to you

    Wow, a whole year. To paraphrase the Grateful Dead, what a strange trip it’s been. We launched devopsy.kinsta.cloud a year ago today with perhaps the naive notion that DevOps was going to really change the way organizations do IT and business. That it was almost inevitable that DevOps was going to move beyond the realm of early adopters and visionaries, beyond startups and Unicorns and see adoption by enterprises and businesses of all sizes and shapes. You know what? We were right!

    DevOps has skyrocketed onto the mainstream IT consciousness and we were lucky enough to have a first row seat here at devopsy.kinsta.cloud. We are even proud of the fact that maybe we even played a small part in this adventure.

    But let’s be real. It hasn’t been all sprinkles and smiles. We have learned a lot of lessons along the year and usually the hard way. But sometimes the hard way is the best way to learn them. We knew that our audience was going to be a technical group. They would want to hear about and from people who had problems and issues similar to their own and how others solved or addressed the issues. We knew that they liked to find out about different tools that can help you keep the IT machine humming along.

    We defined our mission as pitching a big tent for DevOps. I said it in the very first post one year ago today. To me personally pitching that big tent meant that we weren’t just about the existing DevOps community, many of which were early adopters, thought leaders and visionaries in the space. In my mind this group represented only about 15% at most of the eventual DevOps community. I realized that though some people were talking about and instituting DevOps principles for some years already, the majority of our audience was going to be new to DevOps. I wanted devopsy.kinsta.cloud to have a place for everyone interested in DevOps.

    That right there has also been the source of some of our biggest mistakes and angst over the year. We definitely took some time finding our legs under us. Finding people with the credibility that others would respect, striking the right tone, fine tuning the mix of articles and topics. At each step along the way we made some missteps. Many in the community didn’t mince words in pointing out what they didn’t like. Others remained silent and just ignored us. We took our lumps for sure, but we just kept putting one foot in front of the other, putting out new fresh content every day.

    Many times readers or just people piling on via Twitter took us to task about what people wrote in their articles. We had and still have no problem with readers disagreeing with what an author writes here on devopsy.kinsta.cloud. It is healthy to have debate. But we were surprised that people would think that we wrote the particular post or article. Or that is what we espoused. Just not the case. We don’t agree with what everyone writes here. However we think people have the right to write what they believe in. We think giving people a place to write means not censoring or telling them what to write.

    Finally we started catching stride. Since the summer months our entire business has been on a rocket like trajectory. Here are some salient metrics:

    1. We are on track for a 100k view month for March. This represents a 100% increase over just November 2014.
    2. Our twitter, facebook, Google +, Linkedin following has grown exponentially
    3. We have published over 630 articles in the past year, by well over 125 different authors!
    4. We have produced or been media sponsor for 10+ events (with many more coming this year)
    5. We have produced 8 webinars
    6. A DevOps salary survey
    7. Fulfilled our goal of becoming the single largest collection of original DevOps related content on the Internet.
    8. We published over 50 newsletters and now offer several options on how you want to receive your devopsy.kinsta.cloud news.

    At a time when media companies like GigaOm are going under. When other media outlets are laying off paid writers, relying on unpaid bloggers, devopsy.kinsta.cloud is adding to our featured writers. At the same time continuing to publish more fresh, original DevOps content than anyone. Other sites have taken to syndicating blog posts from others, republishing stories from elsewhere. At devopsy.kinsta.cloud you can be sure that when we publish a story it is the first time that content has appeared on the Internet.

    We have spent a lot of time thinking and planning for the coming year. We think that 2015 and 2016 will be big years for DevOps. We want to make sure we do our part and continue our growth. Look for many new features and new takes on distributing DevOps content and engaging the community this year.

    If you look in our about section today you will see a near final draft of our editorial calendar. Our new media kits is also almost ready. You can see a near final draft of that in our sponsor page. Yes, 2015 promises to be even better than 2014. I am sure there will be some missteps this year as well. Hopefully we have learned from our past and there will be less.

    Most of all on behalf of everyone associated with devopsy.kinsta.cloud, I want to thank each and every one of you reading this article for your support this year. Without your support, none of the amazing things that has happened so far would be possible.

    So happy birthday devopsy.kinsta.cloud. Here is to many more. Also did I mention the first 50 people who tweet with #happybirthdaydevopsdotcom will receive a special edition t-shirt. Thanks again!

  • DevOps & Continuous Change

    DevOps & Continuous Change

    A remark by a colleague while waiting for the coffee machine to complete its cycle started my train of thought. “Should we have multiple minor releases or just do a few major ones in a year?”

    In large organizations, due to many factors, the turnaround time for a single successful release is quite extensive; but if the conceptual change which we are talking about bringing whilst using the #DEVOPS methodology would not only reduce these long cycles but deliver quicker and quality software.

    I have already discussed in my earlier article “DEVOPS: Getting our organizations aligned” on the traditional approach and how the combination of this two (DEV & OPS) has been proven beneficial in various organizations and how many are still hesitant in embarking on that path.

    Continuous Change which encompasses both Continuous Integration and Delivery is paramount to achieving this objective. To attain the objective of delivering rapid and consistent value to the stakeholders regularly, we have to have Continuous Change happening.

    I am sure we have already moved out from the Mainframe era to a more Distributed systems state. But unfortunately we have yet to let go of that culture where we pile up components on a single quasi Distributed Application, instead of creating smaller independent, yet interdependent systems.

    So, back to the same question; shall we go with a few Dinosaur sized, labored releases or make multiple short and swifter runs? In my opinion, we should strive towards the leaner model. Easier said than done you say! Agree. If I have to, then I would go about it this way:

    In an environment having a suite of Distributed Applications, start with Analyzing the components which make up the Major release, List out the changes (fixes and new features) which are planned, asses functional and technological impact, Identify dependencies, upstream/downstream connectivity’s, architectural deficiencies, list out the identified subset of components or group of components by functionality, which can go as an independent release.

    I am resisting the urge to say ‘standalone’ as with the current set of complex intervened collection of applications, it would be an incorrect statement. It would rather be a subset of components which can be independently upgraded. Now the big task is to review and decide if this subset or group would add functional value to the overall suite of applications without the rest of components going in.

    Once identified, the success of this release working as expected would be in the extensive testing (Unit/ Regression/Performance) of these components, and as we gain confidence in this split and deploy procedure, we can start with, prioritizing and scheduling critical must have features or bug fixes which also should be backward compatible with other components lagging behind. We can even come up with scenarios where these components are not just getting updated frequently, but would also have multiple independent tracks. Of course it goes without saying the testing and signoff process is strictly followed albeit in a shorter window.

    Deployments to production have always been a source of heartburn to the OPS teams, we have often seen finger pointing and firefights to contain change fails. In order to maintain stability and maximize availability, stricter controls and reduced deployment windows are put in place. In promoting frequent and smaller component level changes, OPS will also be in control of what’s going in, and smaller component level releases can be rolled back quickly within the Green-Zone window if the change is not working as expected. Though I would categorize this rollback, as a process fail than a deployment fail, and should be reviewed very seriously with right mitigation plan and lessons learnt retrospection, Continuous learning after every successful or failed sprint ensures competent and confident releases.

    Another major factor impacting multiple runs of Production releases is the long Green-Zone windows, by moving to the quicker and leaner deployments cycles, these requests can be substantially reduced, and can eventually aim to reach a stage where changes are deployed online without extensive downtime.

    Similarly, frequent maintenance activities when there are no planned deployments, effectively has the same risk on environment unavailability. Analyzing and moving to a state where these activities are conducted online without a Green-Zone would alleviate the maintenance downtimes and ensure seamless availability, adding stakeholder value.

    I have not touched on the Continuous Integration or the Automation of the deployment process for obvious reasons, we can’t achieve the objective of Continuous Change without having the Integration process in place where incremental changes to code are build into a package swiftly and seamlessly, even a sanity or basic testing might be integrated to ensure the quality of the builds. Same goes for automating the deployments, develop & integrate tools required for rapid deployments. We have seen instances where automating a single activity or revisiting a process has created substantial time savings.

    While it’s easy to propose changes to the Release Process or advocate rapid deployment cycles, we have to ensure adequate checks and balances are in place, compliance adherence and audit trails are created.

    Now to the most important measure of this article, Cost Savings!

    Proponents of the Dinosaur Releases would argue that the common activities which entail a single release like the builds, Testing, Release Management, OPS availability or reduced GZ would cut costs and multiple runs to PROD would logically increase costs.

    But it’s definitely the other way around, we wouldn’t need to feed the Dino anymore, it will be a cost worthy rapid delivery with optimized resources, a leaner process where DEV and OPS are working together to ensure quality value added deliverables are made available to business faster.. This cultural change and collaborative effort also creates new vistas of growth and provides a perfect platform to excel. The cost benefit analysis would eventually be in favor of Continuous Delivery.

    Opportunity cost is another variable which has not been considered; an innovation or a new feature available to customers quickly with reduced time to market cycle will provide the much needed edge in these competitive times. I recall some conversations where a few must have’s were pushed out due to various reasons, frustrating the business.

    DEVOPS was never meant to replace the traditional approach to software development; rather it is an efficient use of the existing resources within a collaborative model to rapidly deliver quality software products. A major cultural shift in our approach is required and to reach that goal we need to embrace the shades of grays, many a times over 50 (sorry, couldn’t resist) when it’s not truly black or white.

    Thank you for the time.

    Visit my blog http://askhurram.com/

    Read On, Live On.

     

  • Some changes to devopsy.kinsta.cloud

    Some changes to devopsy.kinsta.cloud

    Well if you are reading this you are one of almost 40,000 unique visitors to devopsy.kinsta.cloud in the last 6 or so weeks. In this relatively short time we have learned a few things. Based upon these we are making a few changes to devopsy.kinsta.cloud. Some you will see right away, some you will see phased in over the coming days and weeks.

    Here are some of the changes we are making and why we are doing it:

    A. Blog Neighborhoods – From the beginning my vision of our many bloggers and blogs was to organize them into “neighborhoods” that would allow people to hone in on what is important to them.  Unfortunately the neighborhood aspect was not well implemented and all of the blogs were lumped together. Going forward you will see our bloggers and blogs grouped into the following areas:

    1. Enterprise DevOps – This is for DevOps in the large enterprise. Organizations doing DevOps by choice.  This neighborhood will feature stories, tips and tricks on adopting DevOps in a large organization and how to make it work. We have some excellent bloggers in this section and will be adding more.

    2. Doin’ DevOps – Formally the DevOps Life section, this is a neighborhood of DevOps practitioners. Not vendors, people who practice DevOps and work and are sharing their experiences. If you are looking for more technical content, this is a good place to find it.

    3. SecOps – This is for DevOps and Security related content.  Again we have some excellent writers in this section and the security tips range from very technical to how to integrate security into the Dev and Ops process.

    4. DevOps in the Cloud – This is primarily startups and companies using the cloud almost exclusively for their infrastructure. Sort of the opposite of the Enterprise DevOps neighborhood.

    5. DevOps Toolbox – This is going to be primarily vendors writing about their DevOps tools here. Yes, you can take what they say with a grain of salt. But to discount them because they are vendors would be a mistake. No one knows their products and use cases better than the vendors themselves. Not to mention that they have experts in the field who will be contributing. There will be much to be learned here!

    6. The Business of DevOps – like it or not, DevOps is on its way to being a genuine commercial business process. There are companies, executives, investors and managers who are exploring the business of DevOps. Sort of the Yin to Doin’ DevOps Yang.

    We hope by calling the neighborhoods out like this it will make it easier for you to zero in on exactly the type of content you enjoy. We recognize that many of our readers are very technical engineers. There are also many others coming to DevOps who are not. We will continue to strive to make devopsy.kinsta.cloud the best it can be, pitching a tent big enough for all.

    B. Newsletter

    Thanks to so many of you who have signed up for our newsletter. Try as we may, we have just not been able to get our RSS generated newsletter to look the way we want it to. Instead if you receive our newsletter you are getting a fire hose of posts. There are too many of them and they are too long. So instead we are going to move to a hand curated newsletter that will only be sent 2 to 3 times a week depending on how much content is on the site.

    C. Building out community features – The business directory is up with some listings.  I encourage vendors to take ownership of their listings and make them better. The pages are actually getting lots of views every day. It wouldn’t hurt. Our jobs board beta is up, but we need more listings. If anyone knows of job listings in the field, this is a good time to put a free listing up there. We will add more community features shortly, so stay tuned.

    We are also adding more content and writers. If you would like to contribute to devopsy.kinsta.cloud, write to me ashimmy@devops.com and we can see if you have what it takes.  Thanks for taking the time to read to the bottom and supporting devopsy.kinsta.cloud