devopsy.kinsta.cloud

Tag: java

  • IBM CTO Sees Bright Future for Java in 2018

    IBM CTO Sees Bright Future for Java in 2018

    Significant advances in microservices written in Java, as well as tighter coupling between Java applications and containers, are set to transform the way most organizations build and deploy Java applications by the end of the year.

    IBM Java CTO John Duimovich, as part of five Java predictions for 2018, noted that The Eclipse Foundation has taken over the development of MicroProfiles, a baseline platform definition that optimizes Enterprise Java for a microservices architectures, and the EE4J project, an effort to create standard application programming interfaces (API) for Java runtime. This, he said, will make it much easier to build next-generation Java applications using programming tools based on the Eclipse integrated development environment (IDE).

    In some instances, those applications will take the form of a microservice that gets deployed using a Java runtime. In other instances, those applications will be deployed using containers such as Docker. Duimovich said it’s not only a matter of time before containers and runtimes including Java will become more tightly coupled. That will result in more consistent memory management and easier wiring between Java constructs and containers. For example, Java applications will be able to determine automatically how much memory is available to any given container. That’s critical because the reason most containers fail is they exceed available memory limits, he said.

    Duimovich also predicted that Kotlin will be the next big variant of Java to be adopted in the enterprise. Concise coding syntax plus interoperability with other instances of Java have already made it popular for many developers. Now that Kotlin can be used to build applications for devices running Android, this year will see much broader usage of Kotlin to build greenfield applications, Duimovich said. However, he added, it won’t be too long before other variants of Java start employing similar concepts.

    Related Content:

    Hopes and Fails in DevOps 2017

    DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    Other major Java predictions for 2018, Duimovich noted, will be optimization of Java runtimes for serverless computing frameworks and a more regular six-month release cycle for incorporating new functions in Java. The rise of serverless computing frameworks will also result in more Java applications being deployed on public and private cloud services, he said.

    Duimovich noted that, from a practical perspective, a Java runtime is simply another type of container. The challenge facing DevOps teams will be determining when and where to use Docker containers instead of traditional Java runtime to deliver an application. Whatever the outcome, it’s unlikely any IT organization will standardize on one approach to the exclusion of all others.

    The increased rate of Java innovation can be attributed to an Oracle decision made last fall to place Java Enterprise Edition under the auspices of the Eclipse Foundation, said Duimovich. At the same time, IBM moved to open-source its implementation of a Java virtual machine. This has resulted in something of a Java Renaissance, as more developers and organizations are contributing expertise via the Eclipse Foundation.

    There’s no shortage of programming language options available these days. But in many cases, if Java is able to build modern applications, then it’s probable many developers will continue to use Java rather than take the time to learn something new.

    — Mike Vizard

  • Core Factors Influencing Java Memory Consumption

    Core Factors Influencing Java Memory Consumption

    Java is known for having an insatiable appetite for resources, requiring strict controls to not exceed budget limits. However, the latest JDK updates and other developments have helped to make Java runtime extremely flexible in terms of memory usage. When configured smartly, Java can be cost-effective for different types of applications—cloud-native or legacy, microservice or monoliths. Today, it’s possible to make Java very slim from the start and scale it up gradually without consuming unnecessary resources.

    Here we’ll take a closer look at the factors influencing resource usage inside JVMs, see what tools can help and how processes can be tuned to gain more elasticity and scalability, ultimately reducing TCO.

    Scaling Possibilities: Virtualization vs. Containerization

    Within JVMs there are several scaling options: vertical, horizontal and a combination of both. To maximize results, it is important to start with a vertical scaling configuration that optimizes RAM and CPU usage inside every instance, based on current load levels. As a next step, these settings will be replicated across all instances while scaling horizontally.

    VMs Scaling

    While starting to run a project inside a VM, it is important to pick the right size machine, as too small an instance can lead to performance issues or even downtimes during load spikes. However, over-allocating will result in wasted unused resources during normal load or idle periods that still must be paid for. This can be a tough choice.

    Start with a smaller VM and scale it as the project grows. When just a bit more resources are required, the cloud vendor can offer you to double the size, as this is the most commonly used scaling step (e.g. see AWS offer below).

    During such scaling, the current VM normally is paused to migrate and redeploy the application. This inevitably causes some downtime and requires manual intervention.

    Memory ballooning provides a possible way (although rather complicated) to modify the amount of resources inside VMs on the fly without incurring downtime. However, this process is not fully automated and requires special tools to monitor the memory pressure in the host and guest OS and then activate vertical scaling based on the needs. As a result, memory ballooning doesn’t work well in practice, as the memory sharing should be automatic to present the expected advantages.

    Unfortunately, lack of VM elasticity and efficiency in terms of resource usage often leads to overpaying.

    Containers Scaling

    Containerization presents a new way of application packaging that makes resource consumption more granular and flexible, by automatic resource sharing among containers on the same host using cgroups. Unlike VMs, containers’ boundaries can be easily scaled up and down without the need to pause and reboot running instances.

    There are two types of containers: application and system containers. Both use the same scaling approach but they are intended for different purposes. An application container (such as Docker or rkt) typically is more lightweight, runs a single process and is used mainly for creating new projects, as it is easy to build them from pre-existing Docker image templates.

    A system container (LXD, OpenVZ) behaves like a full OS and can run full-featured init systems. This type of container is preferable for monolithic and legacy applications, as it can reuse the originally created design and important “old school” settings.

    Even system containers are much thinner compared to virtual machines, so scaling up and down takes much less time. And the horizontal scaling process is very granular and smooth, as a container can be easily provisioned from scratch or cloned.

    Garbage Collector Choice

    To maximize the efficiency of the above mentioned vertical scaling inside a Java-based container, it is important to select the appropriate garbage collector (GC) and tune it according to the project needs.

    Let’s review five widely used garbage collector solutions:

    • G1: From JDK 9, this modern shrinking garbage collector is enabled by default. One of its main benefits is the ability to compact free memory space without lengthy pause times and uncommit unused heaps. This GC is considered the best production-ready option for vertical scaling.
    • Parallel: A default GC in JDK8, it is a good option for low pauses but not for memory shrinking. This makes it inappropriate for flexible vertical scaling.
    • Serial, ConcMarkSweep (CMS): Both of these are shrinking garbage collectors with the ability to scale memory usage in JVMs vertically. But in comparison to G1, they require four Full GC cycles to release all unused resources. A new JVM option (-XX:-ShrinkHeapInSteps) in JDK 9 can  speed up memory release by bringing down committed RAM right after the first Full GC cycle.
    • Shenandoah: Shenandoah is a rising star among garbage collectors which promises to be the best solution for JVM vertical scaling. Its main benefit over the others is the ability to shrink in live mode without necessity to call Full GC, which helps eliminate significant performance degradation.

    Let’s compare memory behavior with shrinking G1 and non-shrinking Parallel:

    With Parallel, the unused RAM is not released back to OS. JVM keeps it forever, even disregarding the explicit Full GC calls. So even if your application has low RAM consumption, the unused resources cannot be shared with other processes or other containers as it’s fully allocated to the JVM.

    The modern shrinking G1 garbage collector significantly improves resource utilization compared to the previous example. The reserved RAM increases slowly according to the real usage growth. And all unused resources within the Max Heap limits are not wasted by standing idle, but made available to other containers or processes running in the same host.

    To summarize, Java applications with non-shrinking GC or non-optimal JVM start options hold all allocated RAM. For scaling Java vertically, the garbage collector should provide memory shrinking in runtime. In other words, it has to package all the live objects together, remove garbage objects, uncommit and release unused memory back to the operation system.

    Charging Model of Cloud Providers

    Nowadays, most of the cloud vendors offer a “pay as you go” billing model. This means that it is possible to start with a smaller machine and then add more servers or migrate to a twice-bigger instance as the project grows. But as described above, usually you reserve more than the application actually consumes to avoid the risk of downtime during the load spikes. As a result, many organizations overpay because the account is charged per VM but not based on the consumed resources inside.

    At the same time, there are providers offering  “pay as you use” billing approaches that became possible with the help of containerization, resource granularity and automatic vertical scaling. The payment is based on the resource units inside container. And the required capacity is provided and reclaimed on the fly in accordance with the load at the current moment. As a result, you are charged based on actual consumption and are not required to make complex reconfigurations to scale up or down.

    Taking into consideration all these factors and implementing the right settings can significantly reduce the costs for Java hosting resources, as well as positively influence application performance as a whole. Cloud and container technologies continue eliminating barriers and offering new opportunities for projects with different architectures and budgets.

    About the Author / Ruslan Synytsky

    Ruslan Synytsky is CEO and co-founder of Jelastic. He designed the core technology of the multilingual cloud platform that runs thousands of containers in a wide range of data centers worldwide. Ruslan worked on building highly available clustered solutions, as well as enhancements of automatic vertical scaling and horizontal scaling methods for legacy and microservice applications in the cloud. Ruslan is actively involved in various conferences for developers, hosting providers, integrators and enterprises. Follow him on Twitter.

     

  • NodeSource, AppDynamics Ally for Node.js DevOps

    NodeSource, AppDynamics Ally for Node.js DevOps

    The prevalence of Node.js as the most widely deployed instance of JavaScript is putting a lot of pressure on DevOps teams to find ways to automate the management of Node.js applications. To provide the visibility needed to achieve that goal, NodeSource has announced it has integrated its N|Solid development environment with the application monitoring tools developed by AppDynamics.

    Pravin Halady, product manager for NodeSource, says one of the things that differentiates N|Solid, which is based on Node.js, most is the amount of telemetry data NodeSource is able to collect from Node.js applications. The alliance with AppDynamics provides a mechanism for DevOps teams to now tap into that data to better manage those applications alongside the panoply of existing applications they need to support and manage, says Halady.

    AppDynamics already supports Node.js. But Halady says the alliance with NodeSource provides deeper visibility into, for example, asynchronous activity. Advanced metrics can be used to augment the basic Node.js metrics that AppDynamics currently provides to better ensure service level agreements (SLAs) are both achieved and maintained, Halady says.

    Adoption of Node,js exploded across the enterprise once it became feasible several years ago to deploy JavaScript code on both the client and the server. That capability in many ways fulfilled the early promise of Java in the eyes of many developers. But DevOps teams have been slow to include support for JavaScript applications within their DevOps processes, mainly because of a lack of visibility. Now that the base of Node.js applications in the enterprise has reached a level of critical mass, tools vendors such as AppDynamics are looking to provide that visibility by expanding the scope of support they provide for Node.js.

    Halady says NodeSource chose to partner with AppDynamics in part because in the wake of AppDynamics being acquired by Cisco Systems, it’s clear that NodeSource needs to participate in the end-to-end visibility platforms that larger companies are starting to build. Cisco has already made significant investments in a Cisco Tetration analytics application in addition to committing to imbuing the IT infrastructure environment it provides with machine-learning algorithms. That data will then be combined with data about applications collected by AppDynamics to identify the source of any potential performance issue faster. NodeSource, adds Halady, will look to foster similar agreement with other providers of application monitoring tools.

    In the meantime, DevOps team can take heart in the fact the Node.js Foundation is making providing visibility into DevOps environments a higher priority. The number of Node.js applications in the enterprise is only expected to increase. There’s a high correlation between usage of Node.js and containers that collectively are being used to facilitate the development of microservices. As those microservices bgin to replace monolithic applications developed originally developed in languages such as Java, the size and scope of the DevOps challenge exponentially increases.

    Application development in the enterprise is going to be polyglot well into the next decade. Today there are more programming languages being actively used in the enterprise than any time in history. In fact, the days when IT operations could mandate what technologies developers can employ are long over.

    — Mike Vizard

  • Continuous Delivery: The Atlassian Way

    Continuous Delivery: The Atlassian Way

    Sonatype’s Mark Miller (@TSWAlliance) caught up with Ian Buchanan (@devpartisan) for our 2016 DevOps Leadership Series. Ian discussed his experiences at Atlassian, including continuous delivery, ChatOps, and use of tools such as Bamboo, Nexus, Puppet and Datadog.

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

    Buchanan: I’m Ian Buchanan. I’m a Developer Partisan at Atlassian, which is developer advocacy for our developer tools.

    Miller: Ian, most people know Atlassian from solutions like JIRA and Bitbucket.

    Buchanan: Yeah, I focus mostly on Bitbucket and Bamboo. Bamboo’s our continuous integration and deployment tool.

    Miller: Good. One of the subjects we talked a little about at dinner last night is how Atlassian is using Nexus. Can you give us some background on that?

    Buchanan: Yeah, that’s right. Well, we’re a big Java shop. We have been for a very long time and have a lot of Maven dependencies for external reasons; we also store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     We’re a big Java shop. We have been for a very long time … we store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     Miller: As far as a binary repository, are you using it for anything other than components?

    Buchanan: Not that I’m aware of. I know that we’ve recently started to get into Docker quite a bit and Nexus is a good fit for that as well. I don’t know the extent which we’re using Nexus for that purpose yet, as Docker’s still quite new for us.

    Miller: What does your continuous integration pipeline look like?

    Buchanan: It certainly varies by product in the details. Of course, we have our own continuous integration product, Bamboo. Bamboo is the most pervasive tool we have.

    For the Java stuff it’s pretty simple pipeline where libraries get built and published into Nexus so that they can be used downstream. We also have some interesting, newer cloud products that are built with Python. A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    Miller: Are you guys using continuous delivery in house for your workflow?

    Buchanan: We’re in an interesting position that I think I see a lot of companies in. We have some behind-the-firewall products (our server products) and then we also have cloud products. In the cloud side, continuous delivery is used when we want to go very fast. But we also have to balance that with the approach we take for our server products so that they don’t fork terribly. We have continuous delivery up until there’s a product delivered. At that point, there is another kind of pick up—where the cloud products engage with other things like Puppet and Ansible to configure the environments with products that other people can pick up and run on premises.

    Miller: I was talking to your team in San Francisco. How are you guys using ChatOps with HipChat?

    Buchanan: I’ve been talking about ChatOps for quite some time. We do a lot of very interesting things with ChatOps. They play a very important part of our continuous delivery pipeline in that we publish build results in there. People can see when pull requests are ready and check those out. We get to see what’s happening from production as well. We have integration with Datadog; it tells us some of the monitoring things that are going on. It’s not just information coming into the chat room. There are also commands that folks can issue to make the continuous delivery pipeline move along. There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

    _________________

     There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

     _________________

     Miller: Anything coming up in the future you guys are working on that’d be fun?

    Buchanan: Well, a lot of the innovation really happens at our quarterly “Ship It” events. That’s where our developers spend 24 hours doing whatever kind of innovation interests them. A lot of time is spent scratching an itch they have. Some of the things that I saw there were about having more information coming back upstream, not just into the chat rooms, but into JIRA where more of the longer-term tracking is going on. They’re experimenting a lot with putting more information into JIRA.

    Miller: Nice. Final question, if you were going to be a superhero, would it be Dev, Sec or Ops?

    Buchanan: I’ve played Dev roles and Ops roles and I almost feel like I know those much more. But from a lot of the sessions at DevNexus, I have to feel like Sec is the superhero. They’re the superheroes because they solve some unsolvable problems in a lot of ways. But I don’t feel ready to play that role at the moment, myself.

    Miller: It’s interesting. I agree with you that they are unsung heroes. Most of the time they just get hammered for what they’re doing.

    Buchanan: That’s true. Yesterday I was in a session about securing REST endpoints. The speaker went through problems with BASIC off , DIGEST off and J2EE—all of these things which we use in our products. At the end we’re left with, “What is the answer?”

    Well, the answer is that for each of these, there are different problems. So we have to identify the right context. We have to understand where some things are broken, know that those things aren’t perfect, and design for that imperfection. That’s a mindset that we have to carry through dev, ops and sec. I hope more security folks step up and start telling those stories.

  • DevOps Transforms Copyright Clearance Center

    DevOps Transforms Copyright Clearance Center

    Copyright Clearance Center (CCC, www.copyright.com) works primarily with business, academic, and medical institutions, enabling them to access the vital content that supports their work. CCC manages fee payments to the license holders and content creators who own the content. DevOps approaches have transformed CCC, a global leader in content rights-licensing solutions, resulting in expanded service to an increasing market.

    “In production, CCC is already processing millions of dollars in transactions. This came to life within a year of the inception date for the DevOps project. For a startup that would be fast. For a medium-sized enterprise, I think that is outstanding,” says Babis Marmanis, CTO & VP of Engineering, Copyright Clearance Center.

    The DevOps transformation that took place in the internal structure of CCC’s engineering department continues today, allowing the organization to respond to the massive disruption in the publishing industry, which is due in part to digital content and the Internet. Using DevOps, Marmanis and CCC have accelerated product development, sped time to market, and provided a stronger consumer experience with the product.

    Accelerated Product Development

    “The Copyright Clearance Center vision is to create the most comprehensive portfolio of global licensing and content solutions (products) that make copyright work for everyone. My product platform strategy stems from that,” says Marmanis.

    CCC has multiple software-based products, each performing the same or similar functions and acting on the same or similar data. “There are certain fundamental things that we must abstract appropriately and encapsulate into common components to make development work optimally,” says Marmanis.

    But when Marmanis came to CCC, there were no common components. And what is more the internal systems lacked interoperability, skills were different across internal teams, and there was no cohesiveness to the development approach. These factors slowed software product development.

    A DevOps mindset was crucial to changing the status quo, to treating infrastructure as code, and to bringing in automation, says Marmanis. A DevOps approach would help to speed the delivery of software projects into the marketplace.

    “Now we use Jenkins (www.cloudbees.com) to glue together elements of the continuous integration process. We have Jenkins build jobs that retrieve the source code from GitHub (https://github.com). We publish software artifacts to Artifactory (www.jfrog.com),” says Marmanis.

    For each release, Marmanis’s teams use Jenkins to execute Chef (www.chef.io) recipes. They deploy artifacts from Artifactory onto a pre-specified execution environment. “In addition, and this is key to the overall scheme, we execute the schema updates with Liquibase (www.liquibase.org), and everything is coordinated with Jenkins,” says Marmanis.

    Further, CCC built its cornerstone platform from the ground up using DevOps-related tools, build detection software, and software libraries. The infrastructure that CCC added is based on best-of-breed open source libraries.

    “Using programming languages such as Java (www.java.com) and Groovy (http://groovy.codehaus.org), Gradle (www.gradle.org) scripts, postgreSQL as the relational database, Liquibase for database objects, Tomcat (http://tomcat.apache.org) as a servlet container, Apache Camel (http://camel.apache.org) for messaging and enterprise integration, and countless other tools including Apache Directory Studio (http://directory.apache.org/studio) and Bootstrap (http://getbootstrap.com/)—the list is very long—we were able to create a harmonious ecosystem,” says Marmanis.

    Stronger Consumer Product Experience

    CCC offers its consumers a better product experience through DevOps approaches and through a homogeneity of standards and technologies, which is available when using open source tools.

    “When we’re building the product platform, these initiatives allow us to embody timeless design principles such as crisp abstractions, but also allow us to scale in a number of dimensions including the number of works that we can represent, the number of publishers we can admit and manage, the number of customers that we have, the number of applications that we can build and deploy, and the number of market verticals that we can occupy,” says Marmanis. This is crucial to customer satisfaction.

    One product that is a prime example of how CCC keeps customers happy is RightsLink for Open Access. “Using RightsLink for Open Access, we facilitate fee collection for articles published under an Open Access license, mediating between the publisher and the author to collect those fees,” says Marmanis. Then CCC aggregates those transactions and presents them to the publisher.

    “Obviously, we give the money to the publisher, but we also create reporting for the authors, publishers, and institutions as well as the founding agencies that gave the money to the author or the institution respectively for funding that research,” says Marmanis. The RightsLink for Open Access product keeps transactions simple, integrating with publisher workflows to expedite publication.

  • Azul Systems Zing Now Certified With Red Hat JBoss Data Grid

    Zing and JBoss Data Grid Deliver Consistent Performance for Best-in-Class In-Memory Solutions

    “By adding Zing to a JBoss Data Grid deployment, DevOps teams will require far less application and JVM tuning to achieve optimal results.”

    SUNNYVALE, CA–(Marketwired – Feb 11, 2014) – O’REILLY STRATA CONFERENCE — Azul Systems®, Inc. (Azul), the award-winning leader in Java runtime scalability, announced today that Azul’s Zing runtime for Java is now certified and fully supported with Red Hat JBoss Data Grid. Ideal for JBoss Data Grid deployments leveraging larger data nodes in transactional Big Data implementations, Azul’s Zing allows organizations to accelerate time to market, improve application runtime consistency and deliver higher sustained throughput for their JBoss Data Grid-based implementations.

    By deploying Red Hat JBoss Data Grid and Azul’s Zing together in business-critical use cases, organizations can scale up (into servers with larger memory configurations) or out as required, without sacrificing performance. JBoss Data Grid provides fast, in-memory data access and elastic scale out, while Zing eliminates all JVM-based performance hiccups, drastically reducing peak latencies and providing unprecedented response time consistency. The combined solution is especially attractive for organizations looking to scale up memory heap sizes or store large in-memory datasets on fewer nodes while delivering predictable application performance.

    Azul’s Zing is designed for enterprise Java applications and workloads that require any combination of large memory, high transaction rates, low latency, consistent human-scale response times or high sustained throughput. Zing provides the following benefits for enterprises implementing JBoss Data Grid:

    • Simpler deployment topology: Zing enables operational simplicity for heap sizes of hundreds of gigabytes per node. This reduces the number of nodes required to store massive data volumes and makes maintenance easier.
    • Consistent response times and SLA compliance: Zing, with Red Hat JBoss Data Grid, has been proven to deliver consistent, low response times in the order of tens of milliseconds at the 99.999% percentile, even with node sizes exceeding 300 GB.
    • Faster time to market: By adding Zing to a JBoss Data Grid deployment, DevOps teams will require far less application and JVM tuning to achieve optimal results.

    “Zing is ideal for Red Hat JBoss Data Grid customers who are looking to scale up memory heap sizes and store large datasets on fewer nodes while still achieving very predictable response time performance,” noted Mike Piech, general manager, Middleware, Red Hat.

    “By combining Red Hat JBoss Data Grid with Azul’s Zing, Java-based businesses realize a significant competitive advantage,” said Scott Sellers, president and CEO of Azul Systems. “Now enterprises can deploy business-critical Java applications requiring large in-memory data sets, consistent real-time performance and scalability in a cost-effective and operational friendly manner.”

    Additional information and benchmark results highlighting the benefits of Red Hat JBoss Data Grid and Zing can be downloaded here:http://www.azulsystems.com/partners/jboss_data_grid_performance_brief_pdf
    More information about JBoss Data Grid is available at http://www.redhat.com/products/jbossenterprisemiddleware/data-grid/
    Further information about Zing is available at www.azulsystems.com/products/zing.

    About Azul Systems

    Azul Systems (Azul) is an award-winning provider of Java for the enterprise. Based in Sunnyvale, CA, Azul has been delivering Java solutions for more than 10 years. The company has deep domain knowledge in Java runtimes, low-latency applications, elastic memory, Pauseless Java Garbage Collection and runtime resource monitoring. Azul is also a member of the Executive Committee of the Java Community Process (JCP.) Azul’s enterprise products enable organizations to simplify their Java-based operations while achieving lower peak latencies, improved scalability and throughput, greater response time consistency and dramatically improved development and operating costs. For additional information, visit: http://www.azulsystems.com.