Category: Blogs

  • Follow the Unicorn: Transform your Enterprise Applications

    Follow the Unicorn: Transform your Enterprise Applications

    For those of us that work on Enterprise Systems such as the mainframe, the claims that the Unicorns (1) make, can be pretty astounding. Dozens and sometimes hundreds of releases a day from big companies like Netflix (2) and Etsy (3) are hard to comprehend. But look a little closer and you can see that the key difference is in the way changes are released to customers, not so much the total volume of changes. A traditional enterprise application may have thousands of changes made over the course of 3 to 6 months, but all of those changes are released at once. The Unicorns are typically able to release a very small number of changes at a time because they can develop, build, test, and deploy these changes very efficiently. Small batch releases to customers has significant value. It enables you to get feedback very quickly, and it is significantly easier to verify because the change is not mixed in with other changes.

    So how can you transform your development environment to deliver small batch of changes? I like to tackle the problem like any other computer science problem, no doubt because of my background. Break the large problem into a set of smaller problems and then solve those smaller, less daunting problems:

    Step 0: Start with a Proof of Concept

    Pick a Proof of Concept (PoC) to begin with that is important, but not mission critical. The PoC can be used as a learning ground and hopefully as a template for subsequent PoC’s. Make sure you have a team that culturally is willing to transform. Often the hardest issues to tackle have nothing to do with technology, but are cultural.

    Step 1: Understand your Application

    You need to have a good understanding of what your application consists of. Not only does the source code make up the application, but what source files are used, what the middleware configuration might be, what scripts you may have to build and deploy the application, and what data files (e.g. flat files, databases) that you use are also important. Some of these components may be shared with other applications, so you need to understand those dependencies as well. Once you have a good handle on the application, you can then automate the application build and deployment process so that all members of the team can work efficiently.

    Step 2: Understand your test cases

    If you can build and deploy the application quickly but it still takes days or weeks to test, then testing prevents you from delivering to your clients. An important shift for testing needs to be from testing the entire application to testing the change. You need to focus on running the right tests to ensure the change is correct and causes no regressions. Tests that do not exercise the code change are irrelevant and can be skipped. For many existing applications, the test suites may consist of hundreds if not thousands of test cases. Many of those test cases may be duplicates or testing areas of the code that are not being changed.

    Step 3: Understand your processes

    How fast can you get your updates to your customer? If your bug fixes and enhancements have to sit on the shelf for days, weeks or months before the customer gets them, they will not be satisfied. Streamline not only the development processes but the operations processes in your organization.

    To know more about the topic with the help of a real life case, watch the replay of a recent webcast which IBM in partnership with DevOps.com hosted with Canada Mortgage Housing Corporation’s Jeff Blackadar on how breaking down IT silos helped speed up mainframe development for them.

    Also, do let me know your thoughts on the blog and on the topic.

    1 the born on the web technology teams

    2 http://www.slideshare.net/jedberg/devops-at-netflix-reinvent

    3 http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches

     

    About the Author/ Mike Fulton

    MikeFaceMedium-150x150A IBM Distinguished Engineer, CTO Enterprise DevOps at IBM,  Mike is a software development professional specializing in compilers, debuggers, profilers and virtual machines. At IBM, Mike works towards understanding and influencing trends and directions in Enterprise IT delivering new technologies into the DevOps Portfolio. He also overlooks integration of the DevOps Portfolio into IBM and Enterprise Software Solutions. Mike is an IBM Master Inventor with several patents to his credit.

    He is an avid blogger and regularly writes on his blog site – makingdevelopersliveseasier.wordpress.com

    linkedintwitter

  • Software Development of the Future: Partnering with Outside Sources How One Company Found Success with Outsourcing a Major Project

    Software Development of the Future: Partnering with Outside Sources How One Company Found Success with Outsourcing a Major Project

    Untangle develops and designs security software and appliances that protect computers and enterprise networks. By synthesizing enterprise-grade capabilities with consumer-oriented simplicity, our company creates products that are both powerful and intuitive to use. Designed for organizations ranging from small schools and businesses to large campus environments, our open source solutions offer a cost-effective alternative to expensive, inflexible proprietary software.

    In 2007, we were at a crossroads in our software development efforts. We needed to implement a major technology upgrade without delay, but didn’t have internal resources to support the project. The technology at the core of our firewall application with desktop user interface was becoming obsolete, and we needed to replace the existing Java Swing-based user interface with one that was web-based. Building a new UI was not just a massive project; it was a crucial one as well.

    The Untangle Next Generation Firewall includes both free and paid apps that block unwanted content, spyware, and viruses from networks. Our Internet Content Control product gives users insight into and control over all their Internet traffi­c for optimal Internet performance. The usability of the Untangle Firewall was one of the product’s most distinct features. Many of our customers were small businesses and academic institutions with users who were not technical experts, so our management team had to ensure that the new UI delivered the same intuitive user experience as its desktop predecessor.

    To take on development of the new UI, we needed to dedicate a new team of software developers for well over a year. Building a development team based in Silicon Valley was impractical in terms of both cost and availability. Competition for top technical expertise was fierce in Silicon Valley and, as a result, compensation levels were skyrocketing. We ended up selecting Gemini Solutions for the project because they were capable of performing highly complex development work and also had capabilities working with JavaScript libraries, a key requirement of the UI project.

    The Untangle Firewall with its new, web-based UI was launched 18 months after definition. The new browser-based product was a resounding success with our customers. Some firewall products completely ignore usability, but we’re passionate about it. Gemini’s expertise with JavaScript made it possible to replicate the user experience while entirely changing the underlying technology.

    Today, Gemini continues to manage the migration to new JavaScript libraries and supports Untangle with other ongoing software development projects as well. These days, JavaScript libraries are very fancy and, as a result, every migration is a big complex project requiring deep knowledge. Gemini has unsurpassed expertise in this area and maintains ownership of that portion of our development.

    The best advice I can give a company looking for outside software development support is to find an organization worthy of their trust and then to trust them fully. Talented individuals want to be an integral part of the team, and they deserve to be. I would highly recommend looking to outside support when you are working on major products. Make sure that they are a good cultural fit, aren’t passive and aren’t afraid to push back. You want a team that will take initiative and offer suggestions. That’s an element that’s missing in so many outsourcing arrangements, so it is important to do your research before selecting a firm.

    About the Author/Dirk Morris

    dirkWhen he’s not summiting El Capitan or off-roading in Baja, Dirk Morris spends his time as the founder and engineering visionary behind the Untangle network gateway platform. Prior to Untangle, Dirk was Chief Architect at Akheron Technologies, where he invented the patent-pending High Bandwidth Transparent Vectoring used in the company’s proxy firewall engine. He has also held positions as lead engineer at VerticalNet and H.L.L.C. Consulting, developing Java-based distributed monitor and intrusion detection systems. Dirk earned a Bachelor’s degree in Computer Science with a minor in Mathematics from Carnegie Mellon University. He worked on survivability simulations at CERT/CC (Computer Emergency Response Team), the University’s renowned, federally funded Center for Internet security.

  • Testing Will Never Be Automated

    Testing Will Never Be Automated

    “Come to think of it, no one speaks of automated programming or manual programming. There is programming, and there is lots of other stuff done by tools. Once a tool is created to do that stuff, it is never called programming again.”

    – James Bach and Michael Bolton, “Testing and Checking Refined

    That’s one of those points that tends to silence a room, as there’s really no way to successfully argue against it, but since similar positions of frustration came up time and time again at the 2015 STAREAST conference, it obviously deserves some further discussion.

    The issue lies in the surprisingly stark differences between the phrases “automated testing” and “test (or testing) automation.” And if you don’t know the difference:

    1. You’re not alone.
    2. You’re likely not a software tester.
    3. You’re discrediting and undervaluing the testing craft.

    The good news is that learning the difference is easy—and testers will forgive you for not knowing it until now! They’re very nice people.

    Here’s what today’s brightest and hardest working testers want you to know. “Test automation applies tools to testing.” They do not automate testing, and they certainly won’t ever replace it. There’s simply no such thing as automated testing.

    And I’m part of the problem. I wrote a column just last year, titled, “Automated testing’s ROI is right under your nose.” I’m somewhat embarrassed that I told the world something that doesn’t even exist provides an immediate ROI—though at least no one went out and bought a completely fictitious tool off of my suggestion.

    Judging by the boisterous cheers as numerous speakers at STAREAST pointed out the absurdity of believing that testing can be automated, this belief is something that I predict testers will likely soon make a concerted effort to erase.

    As companies focus more on collaborative, cross-functional, and quality-minded efforts like agile, test-driven development, and DevOps, testers have an incredible opportunity to clear up any misconceptions about their immense importance to their business.

    Respected tester, author, and public speaker Dorothy Graham recently pointed out a number of these misconceptions in her session, “Blunders in Test Automation” and the very first one on the list was “thinking that testing tools actually do testing.” Sounding almost exasperated at having to point this out, she chuckled, threw her hands up, and said, “They just run stuff, whatever they’ve been programmed to execute, including bad tests.” She almost got a standing ovation.

    When you get that kind of reaction from a room of a thousand software testers from around the world—we’re beyond semantics, and are in a real problem. This is a talented, valuable, and understandably fed-up group of people who are being unfairly cost and productivity-measured against software that provides a completely different service.

    So how did it get this bad, when entire conferences are dotted with calls to action for testers to clearly differentiate themselves from tools, especially when the differentiation is so easy to see?

    One group you may be surprised I’m largely letting off the hook is the tool manufacturers and their marketers. Sure, there are companies that make some claims that testers may wince at, but it’s really hard to find anyone claiming their tool beats, is smarter than, or should replace any human. There’s no reason for them to make these claims; they’re not true, and they certainly won’t help sell the product.

    What about journalists and writers like me who cover the software development and testing industries? After witnessing the frustrations of testers when they feel like they’re being replaced by non-human, non-equivalents—you make a mental note to scratch that phrase from your style guide. I hope other writers do the same.

    How about product owners and others closer to the business side of an organization? Are they contributing to an under-appreciation of the human aspect of software testing? That’s…a little tricky.

    Scott Barber has spent more than fifteen years as a performance tester, but recently experienced (and left) the role of a product owner. While I’m more than familiar with, and a real fan of Scott’s “the truth hurts” speaking style, when he revealed some truths he recently learned, the room grew incredibly uneasy. Many got their first introduction to Scott when he started his session with:

    “It’s not all about testing, you know. Testing is not a product. You are not a product…. Products are the source of profit. And as a product owner, I paid very little attention to testers and testing.”

    It may sting, but it’s the truth. Scott went on to point out that “there’s no need for certain job titles to know or care how things are built or tested. Nobody will ever ask them that.” However, by testers working to gain a much better understanding of the product and the risks that each release candidate poses, there is a massive opportunity to make the value of their work blindingly obvious and positively revenue-impactful.

    Scott’s pro-tip of testers asking a product owner, “Can I do some work with dev and prod so we can get some early observation going on to catch some of these bugs early and head off some of the damage that could come?” drew both a hushed “Wowwww” and “Yeah, I’m using that” from behind me.

    This is where the differentiation between testers and their tools should become clear to everyone. The human levels of empathy, ingenuity, and proactive approach cannot be scripted, automated or baked into any tool, and the best testers care enough about their product and its customers to prove it.

    About the Author/Noel Wurst

    noel wurstNoel Wurst, managing editor at Skytap, Noel is responsible for setting and executing Skytap’s content marketing strategy. That includes overseeing the creation and distribution of high-quality, targeted content, and managing the team and external resources associated with those efforts. By leveraging deep online marketing, project management, and editorial experience, Noel plays a crucial role in helping generate and nurture leads with compelling content.

     Follow Noel on Twitter, @NoelWurst, along with Skytap, @Skytap.

  • 5 Ways Continuous Integration Reduces Risk in Development

    5 Ways Continuous Integration Reduces Risk in Development

    ***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

    There’s a lot of talk about DevOps and Continuous Integration in the tech space right now, but sometimes the implementation of those methods can be tricky.

    An effective Continuous Integration strategy requires DevOps teams to manage risks in software development with a range of practices.

    Here are five processes you can use to make Continuous Integration work for you.

    Automated and Self-Testable Builds

    DevOps professionals can use separate machines for software integration to eliminate the tight coupling between the build process and Integrated Development Environment (IDE) that leads to last-minute integration concerns.

    Everything needed to build the software should be contained in a separate version control repository.

    Dedicated Continuous Integration servers and open source build automation tools can run these builds through continuous testing processes and deploy the product in the required environments.

    Automated deployment further eliminates the bottleneck of waiting for other team members to deploy testable versions of the latest software.

    Synchronize Version Control Repository

    Continuous integration is only possible as long as Dev, Ops, QA and the wider IT team is tightly integrated, collaborative and supportive of each other’s efforts.

    From a tooling perspective, effective collaboration requires a separate-but-unified master database updating changes in real-time.

    All database artifacts — including scripts, procedures and other assets should be placed in this version control repository.

    DevOps teams can enable Continuous Database Integration by using automated database integration, local database sandbox and version control repository to share database assets, as well as empowering developers with capabilities to modify the database and making DBAs a part of the Dev team.

    Build a Stronger Foundation and Expand Test Coverage

    Limiting test cases to individual assets executed at every check-in to the version control repository ensures the continuously integrated builds are defect-free in combined form.

    Tests should be repeatable and performed continuously in virtualized systems replicating unavailable testing environments.

    Continuous Integration methodologies allow you to determine how much of the code was actually tested without much manual intervention.

    Although some code coverage tools can assess the percentage of test coverage by package or class, Continuous Integration systems ensure this coverage is updated in real-time.

    For instance, DevOps teams can run these tools as part of the Continuous Integration server build script every time the version control repository is updated with a code change.

    With this information, untested code would never get through to the next stage and the latest test will be conducted across all areas as required.

    Enhance Project Visibility

    With automated build testing and deployment using a centralized code repository, build feedback mechanisms update Devs and Ops with the latest test results and the necessary progress information.

    In cases when the same level of automation for complex builds seems impractical, DevOps teams using manual procedures must establish a feedback loop to bring everyone on the same page with real-time communication and notification of accurate performance and results.

    These capabilities ensure the same high standard of reporting is maintained for manual testing practices as available for automated build testing systems.

    Follow Consistent Dev Standards

    Quality code forms from the ground up, with adherence to common code and architectural standards established for an organization’s specific requirements.

    Automated inspection tools enable Devs working on short and quick builds to maintain their focus on quality from the very foundation of the software itself.

    DevOps teams should assess every integration build for potential defects that surface after integrating several iterative builds but should be taken care of far earlier during the development stages.

    In Conclusion

    The right toolset is key to Continuous Integration, as is the cultural change that facilitates this DevOps practice.

    Continuous Testing presents several areas of improvement for DevOps teams to develop iterative builds in individual, isolated branches and then merge the latest builds in a unified, single and well-synchronized Master branch.

    The idea is to ensure all risks are mitigated beforehand so DevOps professionals are not bogged down with endless needs to rework the product — and that gives them time to focus on true Continuous Integration.

  • Launching Applications to the Cloud – It’s all about Scalability and Speed

    Launching Applications to the Cloud – It’s all about Scalability and Speed

    It is not hyperbolic to state that today’s web services deal in hyperscale realms when one considers stats such as

    • The Amazon cloud can handle up to 1 million transactions per second during peak loads
    • Facebook was managing 890 million daily active users on average for December 2014
    • There are 500 million tweets sent per day and 80 percent of those are sent from mobile devices

    Ironically, the move to hyperscale web services has been made possible by applications going micro, as in microservices as commonly defined as “small, independent processes communicating with each other using language-agnostic APIs.” The emergence of microservices based application architectures is a revolutionary departure from monolithic app development, which was purpose-built around a single service, e.g. storage management, CRM, etc. In its place now are 10 or more modular, reusable services each owning a limited and specific set of functionality in what might be best illustrated as replacing a singular black box with a set of Lego blocks.

    In turn, this has led directly to key advancements in the application development process, evolving from start-to-finish programming to agile, continuous integration/continuous development (CICD). This model offers two major advantages over the waterfall development approach:

    • One, decreasing software development time to align to the “speed of business” dictated by market factors and not by IT processes.
    • Two, enabling specific modules of an application to achieve “autonomous elastic scale” where instances can be scaled up or down dynamically and on an as-needed basis.

    The software world and its professionals are intimately familiar with these application megatrends, of course. They live it every day. However, they may be less familiar with what’s happening — or to be more precise what’s not happening — with the evolution of networking, specifically in the layer that manages server load balancing or application delivery control (ADC).

    This is so because legacy ADCs were built and optimized for applications that resided in a single hardware platform and at a single location. With the advent of Microservices, the days of a cozy 1-to-1 relationship between the ADC and a monolithic application is quickly becoming a thing of the past. A useful analogy here is to equate the management of these resources with how humans treat cattle vs. pets.

    Application microservices are like cattle in that while these resources are valuable, each resource can be easily replaced. Legacy ADCs are like pets in that they’re not easily replaceable and, at times, require painstaking levels of care and attention.  Indeed, it is clear that the pace of innovation for these networking devices has not kept pace with the requirements of application microservices in their current forms as either hardware appliances or as self-contained VM appliances.

    Though legacy ADCs may be upgraded to be microservice “aware” and even provide certain levels of integration; they are not optimized to support an application architecture that’s built on microservices written in different programming languages and distributed across many different hardware platforms, clouds, and even data center locations.

    The solution requires ADCs and load balancers to evolve to take on more of the characteristics microservices possess (be more like cattle and less like pets), namely:

    • Being tightly aligned with each app microservice and not with the entire monolithic app;
    • Delivering a consistent set of network services in a location-agnostic way, whether the app location is on-premises in a data center or distributed across private and public clouds;
    • Being hardware agnostic, whether the app is on bare metal, in VMs, or even in containers – without requiring additional configuration tools; and
    • Achieving autonomous and elastic scale to support each microservice throughout its useful lifecycle.

    Further, this evolution must be true and profound and not a mere incremental advancement, which has hindered the adoption of software-defined data centers among the large enterprise segments thus far.

    Specifically, ADCs must achieve the concept of “application affinity” which is based on the app-world concept of “processor affinity” where resources are aligned/pinned for specific functions. There are two major benefits to this approach. First, having the ADC resource side-by-side, the microservice will improve the application response time. The application delivery follows the “destiny” of the microservice – it grows, shrinks and moves with the app itself.

    Second, this tight alignment (affinity) enables ADC resources to achieve automatic lifecycle management of microservices without manual intervention, which reduces management complexity significantly.

    In summary, it’s been said that best things tend to come in small packages. Such is the case with the emergence of application microservices, which has paved the way for agile, continuous application development and hyperscale web services.

    It’s time for the ADC to undergo a similar evolutionary path in order to maintain its strategic value as the gateway between the network and application layers.

    About the Author/ Dhritiman Dasgupta

    DD_Exec MugDhritiman Dasgupta  the VP of Marketing Avi Networks.Prior to joining the Avi Networks team, Dhritiman Dasgupta (aka DD) was a Vice President at Juniper Networks where he headed up the data center, security, and SDN marketing efforts.  He launched the award-winning QFabric and MetaFabric systems. Prior to Juniper, DD spent 9 years at Cisco Systems in the LAN and Data Center switching divisions heading up product management for several multi-billion dollar platforms including the Catalyst series switches.  https://twitter.com/mandhriti

  • Webinar: Application Release Automation: Understanding the Needs for Modern Service Delivery

    Webinar: Application Release Automation: Understanding the Needs for Modern Service Delivery

    As large organizations become increasingly dependent on software to stay competitive, application complexity grows. As this happens, managing deployments manually becomes more difficult and slows down the pace of business.

    Join Amy DeMartine, Sr. Analyst at Forrester research and Rohit (RJ) Jainendra, Chief Product Officer at Electric Cloud, as they discuss:

    • How Application Release Automation (ARA) solutions eliminate error-prone manual work, decrease risk and increase uptime
    • The critical features required from an ARA solution to help Infrastructure and Operations teams in large organizations overcome modern service delivery challenges
    • Tips, best-practices and tools for overcoming the challenges of ARA at scale

     Recorded: Tuesday, June 30th , 2015

    SLIDES

    [seoslides embed_id=”9a74743c6933″ script_src=”https://devopsy.kinsta.cloud/embed-script/ara-electric-cloud/8309/” overview_src=”https://devopsy.kinsta.cloud/slides/ara-electric-cloud/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”ARA- Electric Cloud” /]

     


     

    Your Host:

    alan_new_head_shotAlan Shimel, Editor-in-Chief of DevOps.com.  An often-cited personality in the security and technology community and a sought-after speaker at industry and government events.  Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

    Panelists:

    amy-devopsAmy DeMartine is a member of Forrester’s Service Delivery team. Amy’s current research is the strategy, design, organization, and implementation of modern service delivery created through methods such as DevOps and resulting in continuous delivery. Amy holds a master’s degree in Telecommunications and a bachelor’s degree in Electrical and Computer Engineering from the University of Colorado.

     

     

     

    rohit-jainendraRohit Jainendra engages with customers to drive Electric Cloud’s product roadmap and leads the product teams which design, build and deliver products that accelerate the software delivery process. RJ previously served as Vice President at Serena Software and was Chief Architect at Rubiconsoft. RJ holds a Master of Science degree in Computer Science from the University of Wisconsin and a Bachelor of Science degree in Computer Science from Angelo State University.

  • How DevOps could save the world; like your colleagues’ day

    How DevOps could save the world; like your colleagues’ day

    DevOps is about a few things but above all, it’s about communication and understanding each other. In that spirit, I decided to create a new day to celebrate: “Like your colleagues’ day”. The rules are simple:

    The first rule of like your colleagues’ day is: You do not talk about Fight…

    • Each year, on the last Thursday before summer (Thursday the 18th of June this year).

    Thursdays are ideal days to make people happy since they’re right before the week-end but not totally there. Right before the summer as it’s all sunny and nice outside.

    • Present a token of your affection to your dear colleagues. Remember, it is a token, not a romantic dinner for 2 in a 3 stars restaurant in Paris. It could be anything from a rose to a beer after work or anything that makes sense to you and the person who receives the gift.
    • Since DevOps is all about loving each other, the day is called “colleagueS’ day”, meaning that you should make as many people happy as you can. A box of chocolates for a team is a good way to make many happy at once for example.
    • Once again, DevOps is about love so you should also consider this day as a good opportunity to bury the hatchet. If you have notoriously grumpy colleagues, maybe all they need is some consideration. A smile, an uninterested chat (meaning you actually listen to what’s being said and do not expect anything in return) and maybe a sweet or a coffee are excellent ways to make people around you happy.
    • Even better, try to make someone you do not know happy. After all, people you have not talked to yet might be full of surprises, right?
    • Money is not the point. For once, you can bake a cake, you can offer to get coffee for your colleagues, you can listen to them and maybe even share a bit too, after all discussions are better with two or more persons.

    Actions have consequences.

    It’s quite simple really, once you’ve introduced your colleagues to the concept (beforehand for better results) and the day has happened, take a step back and draw your own conclusions.

    The first few times I have tried this, only a few persons followed but as the actions were not focused on one person only, others got to enjoy the day and joined in in later editions. The results were above expectations, people got to talk about food, cakes and pretty much everything that can be said during mingling. Where I really saw a good DevOps potential in this is when people from different teams started to play the game and started to communicate together. Some went for beers after work and got to know each other, making things smoother and easier at work afterwards.

    LYCID is also a good opportunity to have activities. While you can think of a management breakfast, it’s not too hard to imagine a technological lunch where everyone is invited or a wine/beer lottery in which everyone can play. As long as the normal work time is respected, everyone should be happy.

    Don’t stop me now, I’m having such a good time.

    Well, you get the point by now, make your colleagues happy and try to create a better work atmosphere by being nice to each other. But that should also open your mind a bit and maybe you could apply a layer of niceness to the world around you. Let people out before going in the subway, hold the door to the person behind you, try to smile when you think the moment is right (you have to figure that out for yourself) and why not, give your change to the first person in need you see.

    This can sound naïve, maybe borderline stupid but imagine a world in which people were nice to each other, no matter the social class, gender, religion… If we were a bit more tolerant, a touch nicer to everyone and a tad less self-centered, this world could actually be really pleasant to leave in.

    Add a pinch of DevOps in that and what do you get?

    Repeat the operation as many times as you want, being nice never killed anyone. Make it a part of your personal and professional culture to be nice, available and polite. Through an iterative process, determine when you can smile without looking like Forest Gump and after a while it will be automatic, you will naturally become good and this will feel nice, trust me. Check the impact of what you did on your colleagues, measure their happiness and if you think things did not change enough, don’t wait until next year, be spontaneous and repeat the operation. After all, baking a cake and getting the coffee for your team should not take too much time or efforts, should it?

    If you feel this could do a difference, spread the word, DevOps is about communication and sharing. Feel free to improve the rules, feel free to ignore some, in the end, all I want is to make you happy.

    I’ve said this before during a conference but as we talk about unicorns, rainbows and other nice things when we mention DevOps, why not dream that we could also make a little difference in the world surrounding us. A little is better than nothing. DevOps could save the world!

  • Top 3 DevOps Practices for Operational Stability

    Top 3 DevOps Practices for Operational Stability

    Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.

    (more…)

  • Webinar: The Top Redis Metrics that Matter

    Webinar: The Top Redis Metrics that Matter

    Redis provides a fast and persistent memory storage system, superior caching, and the ability to support multiple data types. Redis functions differently from other key-value stores or databases that IT teams have used in the past. These differences can lead to issues such as memory swapping, latency in processing commands and key deletions. All can impact application performance if not addressed.

    Identifying and resolving issues originating in Redis requires an understanding of how this key-value store works as well as visibility into its performance metrics. In this webinar, Matt Williams, Datadog’s Evangelist, and In this webinar, Matt Williams, Datadog’s Evangelist, and Dave Nielsen, Redis Labs’ Developer Advocate, will show you:, will show you:

    • How and where to access critical Redis data
    • How to interpret Redis metrics to detect issues
    • How to resolve these issues, or avoid them all together

     


    Recorded: Tuesday, July 7th, 2015

     

    RECORDING

    SLIDES

    [seoslides embed_id=”dffd58b512c0″ script_src=”https://devopsy.kinsta.cloud/embed-script/the-top-redis-metrics-that-matter/8192/” overview_src=”https://devopsy.kinsta.cloud/slides/the-top-redis-metrics-that-matter/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”The Top Redis Metrics that Matter” /]

     

     

     


    alan_new_head_shotYour Host:

     Alan Shimel, Editor-in-Chief DevOps.com, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

    About Panelists:


    mattWilliamsDatadog
    Matt Williams
    is the DevOps Evangelist at Datadog. He is passionate about the power of monitoring and metrics to make large-scale systems stable and manageable. He tours the country speaking and writing about monitoring with Datadog and when he’s not on the road, he’s coding. You can find Matt on Twitter at @technovangelist.

     

     

     


    dave_nielsenDave Nielsen
    recently joined Redis Labs as a Developer Advocate where he organizes and leads workshops and hackathons to help developers create real-time and scalable apps running on Redis. Prior to joining Redis Labs, Dave was the co-founder and lead organizer of CloudCamp, a community of Cloud Computing enthusiasts and community organizers in 100+ cities around the world.  You can find Dave on Twitter at @davenielsen.

     

     

     

     

     

  • SQL lovers fear not – NoSQL just got friendlier

    SQL lovers fear not – NoSQL just got friendlier

    Today Couchbase, the creator of an Enterprise NoSQL database server, announces N1QL ( pronounced Nickle) at their user conference. N1QL is designed to ease the pain for SQL developers when considering NoSQL, by creating a new query language to sit on top. It is essentially SQL for JSON documents.

    (more…)