Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

An Introduction to WebLogic Server Clustering

An Introduction to WebLogic Server Clustering

This is the second in a series of three articles discussing the clustering capabilities of BEA WebLogic Server 6.1 (WLS). This month we discuss replica-aware stubs, their impact on a clustered system, and how they're used with EJBs.

How WebLogic Can Instrument EJBs
WebLogic can provide clustering logic for an EJB in four possible locations (see Figure 1):

  1. The JNDI naming server, where the home stub is bound
  2. The container
  3. The home stub
  4. The remote stub

The home stub and the remote stub are the most interesting aspects, since both of these objects are downloaded by a Java client and run within the JVM affiliated with the client, not the application server.

WebLogic can develop load balancing and failover algorithms for EJBs not even resident in their own server! Given all of the locations where WebLogic can instrument one form of load-balancing or failover logic, the permutation of options is enormous.

Let's examine one-by-one what a WebLogic server instruments:

JNDI Naming Server
The JNDI naming server is the initial access point for all clients to retrieve a home stub of a session or entity bean. This doesn't apply for EJB 2.0 message-driven beans, however - they take a message-oriented middleware approach. To make EJBs highly available, WebLogic can easily replicate naming servers across nodes in the cluster. Since the home stubs placed into the naming tree are lightweight and serializable, it's easy for WebLogic to synchronize the trees in a cluster so that all of the servers provide a single, joint naming tree to their clients. Developers may choose to make their EJB container available on one server in the cluster or on all servers in the cluster. In the former scenario, the home stub replicated throughout the naming server has a hard coded reference to the home skeleton on the host server. In the latter scenario, the replicated home stub can reference the home skeleton on a different node. In Figure 1, this is represented by Node A.

Note: This doesn't encapsulate initial access logic. Replicated naming servers make the home stubs of EJBs highly available to all clients, but distributed systems will still require some form of initial access logic that load-balances JNDI InitialContext requests to the different servers in the cluster. WebLogic recommends using DNS round-robining, a proxy server, or some hardware local director. All of these technologies give you the ability to represent an entire cluster through a single IP address or DNS name. Each one internally maintains a table of IP addresses and servers that are participating in the cluster and then routes "new" requests using a load-balancing algorithm. Subsequent requests may be re-routed to the server that handled the initial request, depending upon the type of request and the technology used.

WebLogic can provide some load balancing and failover logic directly within the container. WebLogic does stateful session bean replication to provide minimal failover capability. When a stateful session bean is created, a backup copy can be placed on another server in the same cluster. The backup copy isn't used unless the primary fails, at which point the backup becomes the primary and nominates another backup. Every time a transaction on a stateful session bean commits, the bean is synchronized with its backup to ensure that both locations are current. If the container ever has a system failure and loses the primary, the remote stub of the bean fails over to the secondary server and uses the instance that's located there. Stateful session bean replication is a highly desirable feature since it provides noninterruptible access to some business logic. It isn't designed, however, to provide persistent access to data, since simultaneous failure of the primary and backup servers cannot be recovered. Entity beans should always manage persistent data. Node C in Figure 1 represents this.

Home Stub
This object is the first object accessed by remote clients and runs locally on a client's virtual machine (VM). Since EJB compilers generate stubs and skeletons at deployment time, the underlying logic in a stub can be WebLogic-specific. WebLogic can instrument some method-level load balancing and failover schemes directly in the stub. Since the primary action of the home stub is to create or load beans on a remote server, the server in which a bean is ultimately created isn't important. Effectively, every create(...) and findXXX(...) method could load-balance requests to a different home skeleton in the cluster. Node D in Figure 1 represents this.

Remote Stub
The remote stub is instantiated by the home skeleton and returned back to the client. It can perform the same types of load balancing and failover that a home stub can, but WebLogic has to be careful about when it chooses to do so. For instance, if a client has created an entity bean, it's likely that the entity bean will only exist in one server in the cluster. It's too expensive to have the contents of the same primary key active on multiple servers in the cluster if there are not multiple clients all requesting the same entity bean. To increase performance, WebLogic will likely only want to load entity beans in memory lazily when clients request their services. A remote stub that accesses an entity bean cannot freely load balance its requests to other servers in the cluster since the entity bean will only be active on a single server. Essentially, the remote stub is "pinned" to the server that it came from and isn't free to load balance at will. Node E in Figure 1 represents this.

Note: WebLogic Server 6.1 implements the latest version of the EJB 2.0 specification (EJB 2.0 PFD 2, 4/25/01). This version introduced local interfaces, special interfaces that allow a client colocated in the same VM as the EJB to access the EJB using pass-by-reference semantics instead of pass-by-value semantics. This gives a client a performance boost and a more robust object model, since local interfaces can have non-serializable interfaces. However, load balancing and failover of requests for EJBs can only be done for clients not co-located in the same VM. If an EJB container were to fail, it's likely that the entire VM hosting the server would fail as well. This would imply that any local clients would not be available and they subsequently couldn't failover to a container on another server. As a result of this behavior, WebLogic Server doesn't provide load balancing or failover of requests for local clients. Only remote clients can use the load balancing and failover features of WebLogic Server EJBs.

Replica-Aware Stubs
This RMI stub load balancing technology occurs in other places besides EJBs. It uses it to implement JDBC DataSource, JMS Connection Factory, JMS Topic, and JMS Queue objects. All of these objects are implemented as RMI stubs that are "replica-aware" - i.e. stubs that can load balance invocations to different servers hosting the service. For example, the JMS ConnectionFactory interface has a getConnection() method. Since the WebLogic ConnectionFactory is implemented as an RMI stub, subsequent calls to getConnection() will be load-balanced across different servers in the cluster as long as the client is a remote client. This behavior applies to all of technologies listed here.

Stateless Session EJBs
The simplest form of load balancing and failover for EJBs occurs with stateless session EJBs. This section discusses how load balancing, failover, and configuration work (see Figure 2).

Load Balancing
Since all instances of a stateless session bean type are identical, a home or remote stub can have its request serviced by any available object in any server. As long as the request gets handled, the remote stub has no preference as to whether the instance on the first server or the second server handles it.

WebLogic provides a better level of scalability by configuring home stubs and remote stubs to load balance method invocations across servers. Each method call handled by a stub would execute a "ServerChooser" algorithm in the stub to select the server best suited for handling this method invocation. The ServerChooser would return the IP address or connection to the server best meeting the criteria needed for this method invocation, and the stub would then forwards the invocation to that server.

Since all stateless session EJBs are identical, the home and remote stubs have a lot of flexibility in selecting which server should handle particular requests. WebLogic provides some basic load-balancing algorithms:


  • Random: A seed-based, random selection of a server to handle a request. This model can incorporate statistical irregularities over the short term.
  • Round Robin: This popular algorithm sends requests to different servers in a statistically regular way.
  • Weighted Round Robin: A derivative of round robin that favors certain servers, using ratios. Administrators and developers apply relative weights to different servers that determine how much of the load they should handle. One design pattern used in some production systems is to set to zero the weight of a server that needs to be brought down for maintenance, thus eliminating any EJB traffic to that server.
  • Programmatic: You code your own stub-based balancing algorithm as a Java class that's compiled into the stub implementation. The class has a single method that's executed whenever a remote or home stub has to select a server. The method you implement will typically have access to reflection method and input arguments that relate to the method the client invoked. From this information, the method you implement needs to programmatically generate a list of servers or IP addresses of servers to try when the stub needs to load-balance. The order of the list you generate dictates the order of the balancing scheme applied by the stub. This particular algorithm is a great way to implement a staging, test, and production environment for your EJBs. Depending upon the values of the input parameters or the current value of a flag specified in a text file, your programmatic filter can alter requests to different servers depending upon whether you're testing an application or running it in production mode.

    Fault Tolerance
    Load balancing sounds pretty easy to incorporate, doesn't it? Well, for the most part, it is. However, incorporating fault tolerance and failover of your EJB applications is a little bit trickier. There are two main things that an application vendor has to determine to accomplish a successful failover (and to be able to support fault tolerance).

    First, how does a home or remote stub determine if a failure situation has occurred? If an exception is generated, how does a stub know that the exception is a failure condition that cannot be recovered? There are three types of exceptions that a stub can receive: application exceptions (those defined by the bean developer), system exceptions (typically in the form of an EJBException), and network/communication exceptions. Application and system exceptions are clearly defined in the EJB specification and typically are propagated to the invoking client to be handled. Network/communication exceptions such as SocketException, CommunicationException, and others, indicate a much more dire, unable-to-communicate-with server scenario. An application server vendor's stub can intercept all system and communication exceptions and perform a failover to another server - if they can determine that it is safe to do so. Why wouldn't it be safe for them to perform this failover action? Read on for the answer!

    The second main consideration is: At what point in the invocation did the failure occur? There are three possible situations that the stub must address:

    1. The failure occurred before the server-side invocation started. This is a great situation for the stub to be in. If it can determine that a failure occurred after the method request was sent but before it was invoked on the server, the stub can treat this failure as a load-balance scenario and redirect the method invocation to any other available server.

    2. The failure occurred after the server-side invocation completed, but before the response message was properly propagated to the client. This is also a great situation for the stub to be in because it requires no further action.

    3. The failure occurred during the server-side invocation. This presents a sticky situation for the stub. The method that was invoked on the server may or may not have altered some server-side resources that impact future behavior of the system. If the stub makes a subsequent request on a method that impacts server-side resources or data, the stub may inadvertently perform the same altering action twice in a row during a failure recovery, which would cause the system to have indeterminate behavior! If the method doesn't perform any of these altering actions then it could safely invoke the method again; if it does alter the system, it can't.

    Unfortunately, it's very difficult for a stub to positively determine that the system is in either of those states. As a result, if a failure situation occurs, a stub will likely have to assume that the server was in the worst-case scenario (i.e., 3) - even if in reality it was in one of the happier scenarios. So, how's this resolved? WebLogic supports the concept of "idempotence" for methods. An idempotent method is one that yields the same result on subsequent invocations if the same input arguments are passed in. A non-idempotent method is one that alters the state of the system (yields different results) on subsequent executions.

    Types of methods that are idempotent include:


  • Any method that acts as a "reader/getter" method
  • Any method that performs a nonaltering query
  • Any method that accesses a resource manager, but leaves the state of the resource manager unaltered

    As a bean developer, you're aware of the behavior that the methods you write will have on a system. You are responsible for specifying which methods in your bean are idempotent and which are not. At runtime, WebLogic can freely perform a failover switch during a failed method invocation if the method that was being executed is idempotent. After all, if the method doesn't alter the state of the system, then the stub is confident that the existing system is intact and that a new invocation won't have any odd side effects. In situations where a failure situation occurs on a method that is idempotent, the stub will be forced to throw the communication exception that it receives to the client. Your client application will then have to decide whether or not it should try another invocation:


    try {
    MyHome home = (MyHome) ctx.lookup("MyEJB");

    // This should use PortableRemoteObject.narrow().
    My remote = (My) home.create();

    } catch (javax.naming.CommunicationException exception) {

    // This is a type of Naming Exception
    // This is an acceptable exception for me.
    Calling this method again
    // will not adversely impact the system.

    try {
    } catch (java.io.IOException exception) {

    // This must be some sort of socket exception.
    // I don't want to call this method again, so now
    it must be
    // handled in another way that you determine!


    Making a stateless session EJB support load balancing and failover is quite simple. You don't have to change the way you develop the bean. Rather, all configuration is done in the weblogic-ejb-jar.xml deployment descriptor (see Listing 1).

    Stateful Session EJBs
    Now let's examine how load balancing, failover, and configuration work in stateful session EJBs.

    Load Balancing
    With stateful session EJBs, a client is "pinned" to the server object it creates. As a result of this pinned nature of clients to instances, remote stubs are wired to a particular server that contains the instance the client is referring to. WebLogic provides no load balancing of remote method invocations as a result of this behavior.

    However, WebLogic does provide load balancing of remote home method invocations for stateful session EJBs. Since a home.create(...) merely creates an instance on a server, it doesn't matter which server the instance gets created on. WebLogic uses a load-balancing algorithm to direct different invocations to different servers as a result.

    In order for failover to be successful with stateful session EJBs, the state of the stateful session EJB must be located on another machine. WebLogic supports primary/secondary replication of stateful session EJBs to support failover of remote method invocations. A primary stateful session EJB instance is stored in the server where the EJB is created. The container will replicate the instance to a secondary server. If the server that hosts the primary instance becomes unavailable, remote method invocations will be redirected to the server with the secondary instance. The secondary instance will then become the primary and nominate another server to host the secondary instance. The remote stub maintains the IP addresses of the servers that host the primary and secondary instances.

    Just as with stateless session EJBs, all configuration of stateful session EJBs is done in the weblogic-ejb-jar.xml deployment descriptor (see Listing 2).

    Entity Beans
    Now let's look at entity beans, starting with cluster-aware home stubs. Then we can consider read-write entity beans, read-only entity beans, and how to get the best of both worlds by implementing the read-mostly pattern.

    Cluster-Aware Home Stubs
    Just like stateful and stateless session beans, entity beans can have cluster-aware home stubs. This allows for lifecycle methods to be distributed amongst the server instances in a cluster. For example, load balancing can be attributed to the database record creation, deletion, and query functionality behind the create(), remove(), and findXXX() methods defined in the bean's home interface. The EJB 2.0 specification introduced the concept of home methods, business functionality that can be attributed to groups of database records, rather than a single record. Calls to these home methods can be load balanced through the cluster-aware home stubs. As with session beans, an entity bean's home stub is made cluster-aware by setting to true the appropriate home-is-clusterable tag in the weblogic-ejb-jar.xml file.

    Read-Write Entity Beans
    The caching strategy selected for a given entity bean determines the possible clustering behavior of the bean's remote stub. Setting the value for the appropriate cache-strategy tag in the weblogic-ejb-jar.xml file configures this behavior. By default, entity beans are deployed with a read-write caching strategy, allowing clients to use the beans to edit database records. Creating or finding a read-write bean returns a remote stub pinned to a single server, which means that load balancing and failover capabilities are restricted to the home stub. Since, in this situation, multiple beans representing the same underlying database record could simultaneously exist within the cluster, data integrity must be preserved by having each bean instance read from the database before each transaction and write to the database with each commit operation.

    Read-Only Entity Beans
    In situations where only data retrieval is necessary, entity beans can be deployed with a read-only caching strategy. Accessing a read-only bean returns a cluster-aware remote stub, which can load-balance on every business method call - thus improving scalability. In addition, the contents of read-only beans are cached on every host server to avoid database reads, further improving performance. In order to be classified as read-only, a candidate entity bean's methods must be idempotent.

    While EJB clients can't modify read-only entity beans, the data the beans represent can be changed by an external source. With regard to caching, a tradeoff must then take place between quick access to the data and maintaining the most current snapshot of the data. In WebLogic Server 6.1, two data update strategies are available: periodic updates or programmatic invalidation.

    The periodic update strategy is governed by the read-timeout-seconds deployment descriptor parameter. By setting this parameter in the weblogic-ejb-jar.xml file, the container will refresh the data stored in the bean by loading from the database at regular intervals. The advantage of this mechanism is that it's simple and requires no additional programming - all necessary configuration takes place in the deployment descriptor. However, this update mechanism does suffer from one efficiency flaw: the data is blindly loaded into the bean at regular intervals, even if a database update doesn't occur during the established time period.

    Programmatic invalidation overcomes this obstacle, adding intelligence to the update of read-only beans. A developer can trigger a refresh of a single bean instance or group of instances of a certain bean class by invoking an invalidate() method, available through the home interface. When the invalidate() method is called, the WebLogic EJB container will invalidate the appropriate beans on the local server and send a multicast message to all other servers in the cluster to do likewise.

    The added control over when a bean gets updated comes with a small price, however. In order to invoke the invalidate methods, the EJB client must explicitly cast the bean's home stub to either the weblogic.ejb.CachingHome or weblogic.ejb.LocalCachingHome interface (the latter for entity beans whose clients are other EJBs resident in the same instance of WebLogic). These interfaces are BEA proprietary extensions, filling in a performance hole in the current specification. The potential improvement in data access performance mitigates the minor inconvenience of removing such method invocations in the event of migrating the EJB client to another application server environment.

    Applying the Read-Mostly Pattern
    What about entity beans that require occasional programmatic updates? Is there a way to cash in on the performance benefits of read-only beans while still providing write access? Yes: the answer lies in the implementation of the read-mostly pattern, by deploying the same bean class twice - once each with read-only and read-write caching strategy tags. Clients of the read-only bean can benefit from load-balanced access to cached data, while clients of the read-write bean can rely on data integrity during transactions.

    If you're relying on syncing read-only beans with periodic updates, via the read-timeout-seconds para-meter, we'd make the following recommendations:


  • Set all values of read-timeout-seconds to the minimum acceptable values that provide frequent enough updates without sacrificing performance - appropriate selection may be an iterative process for a given application.
  • If the data behind several classes of read-only beans could be updated in a single transaction, make sure to set all corresponding values for read-timeout-seconds identically.
  • Minimize the amount of data updated in the read-write beans and test to make sure that the transactions in which they're involved don't extend past the update intervals of their corresponding read-only beans.

    Certainly, to avoid this optimization process developers can choose the programmatic invalidation mechanism described above. However, this practice would reduce EJB portability since the bean implementation class would contain calls to proprietary WebLogic interfaces.

    A third option, available when using container-managed persistence, is the use of the invalidation-target parameter when configuring the read-write bean in the weblogic-ejb-jar.xml deployment descriptor file. By specifying the name of the corresponding read-only bean within this tag, that read-only bean will be automatically invalidated when the read-write bean is updated. In other words, invalidation-target provides developers with an optimal refresh strategy for read-only beans without sacrificing code portability.

    The weblogic-ejb-jar.xml deployment descriptor file shown in Listing 3 illustrates the appropriate settings for an entity bean deployed with the read-mostly strategy.

    While the concepts behind EJB clustering take some time to digest, the mechanism for implementing load balancing and failover in WebLogic-based enterprise applications is distilled down to setting a few tags within the deployment descriptor files. Certainly, determining the optimal settings for those parameters that are suitable for a given application is an iterative process. However, by isolating clustering behavior to configuration files, WebLogic minimizes the time necessary to reach that level of optimization.

    In the next installment of this series, we'll discuss common architectural practices for tying together presentation and business logic in a clustered environment.

  • More Stories By Tyler Jewell

    Tyler Jewell is VP, Product Management & Strategy, Oracle Public Cloud.

    More Stories By Lawrence Kaye

    Lawrence Kaye is the Manager of Delivery Strategy in BEA Educational Services. He has five years of Java development experience and has taught WLS development and administration courses for the past two years. Lawrence can be reached at [email protected]

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    @ThingsExpo Stories
    Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicate or sell. In their Day 3 Keynote at 21st Cloud Expo, Greg Chambers, Global Group Director, Digital Innovation, Coca-Cola, and Vidya Nagarajan, a Senior Product Manager at Google, will discuss how from store operations...
    Nordstrom is transforming the way that they do business and the cloud is the key to enabling speed and hyper personalized customer experiences. In his session at 21st Cloud Expo, Ken Schow, VP of Engineering at Nordstrom, will discuss some of the key learnings and common pitfalls of large enterprises moving to the cloud. This includes strategies around choosing a cloud provider(s), architecture, and lessons learned. In addition, he’ll go over some of the best practices for structured team migrat...
    SYS-CON Events announced today that Taica will exhibit at the Japan External Trade Organization (JETRO) Pavilion at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Taica manufacturers Alpha-GEL brand silicone components and materials, which maintain outstanding performance over a wide temperature range -40C to +200C. For more information, visit http://www.taica.co.jp/english/.
    SYS-CON Events announced today that MIRAI Inc. will exhibit at the Japan External Trade Organization (JETRO) Pavilion at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. MIRAI Inc. are IT consultants from the public sector whose mission is to solve social issues by technology and innovation and to create a meaningful future for people.
    Recently, REAN Cloud built a digital concierge for a North Carolina hospital that had observed that most patient call button questions were repetitive. In addition, the paper-based process used to measure patient health metrics was laborious, not in real-time and sometimes error-prone. In their session at 21st Cloud Expo, Sean Finnerty, Executive Director, Practice Lead, Health Care & Life Science at REAN Cloud, and Dr. S.P.T. Krishnan, Principal Architect at REAN Cloud, will discuss how they bu...
    As hybrid cloud becomes the de-facto standard mode of operation for most enterprises, new challenges arise on how to efficiently and economically share data across environments. In his session at 21st Cloud Expo, Dr. Allon Cohen, VP of Product at Elastifile, will explore new techniques and best practices that help enterprise IT benefit from the advantages of hybrid cloud environments by enabling data availability for both legacy enterprise and cloud-native mission critical applications. By rev...
    Join IBM November 1 at 21st Cloud Expo at the Santa Clara Convention Center in Santa Clara, CA, and learn how IBM Watson can bring cognitive services and AI to intelligent, unmanned systems. Cognitive analysis impacts today’s systems with unparalleled ability that were previously available only to manned, back-end operations. Thanks to cloud processing, IBM Watson can bring cognitive services and AI to intelligent, unmanned systems. Imagine a robot vacuum that becomes your personal assistant tha...
    With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend 21st Cloud Expo October 31 - November 2, 2017, at the Santa Clara Convention Center, CA, and June 12-14, 2018, at the Javits Center in New York City, NY, and learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
    SYS-CON Events announced today that Datera will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Datera offers a radically new approach to data management, where innovative software makes data infrastructure invisible, elastic and able to perform at the highest level. It eliminates hardware lock-in and gives IT organizations the choice to source x86 server nodes, with business model option...
    Infoblox delivers Actionable Network Intelligence to enterprise, government, and service provider customers around the world. They are the industry leader in DNS, DHCP, and IP address management, the category known as DDI. We empower thousands of organizations to control and secure their networks from the core-enabling them to increase efficiency and visibility, improve customer service, and meet compliance requirements.
    Digital transformation is changing the face of business. The IDC predicts that enterprises will commit to a massive new scale of digital transformation, to stake out leadership positions in the "digital transformation economy." Accordingly, attendees at the upcoming Cloud Expo | @ThingsExpo at the Santa Clara Convention Center in Santa Clara, CA, Oct 31-Nov 2, will find fresh new content in a new track called Enterprise Cloud & Digital Transformation.
    SYS-CON Events announced today that N3N will exhibit at SYS-CON's @ThingsExpo, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. N3N’s solutions increase the effectiveness of operations and control centers, increase the value of IoT investments, and facilitate real-time operational decision making. N3N enables operations teams with a four dimensional digital “big board” that consolidates real-time live video feeds alongside IoT sensor data a...
    SYS-CON Events announced today that NetApp has been named “Bronze Sponsor” of SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. NetApp is the data authority for hybrid cloud. NetApp provides a full range of hybrid cloud data services that simplify management of applications and data across cloud and on-premises environments to accelerate digital transformation. Together with their partners, NetApp emp...
    Smart cities have the potential to change our lives at so many levels for citizens: less pollution, reduced parking obstacles, better health, education and more energy savings. Real-time data streaming and the Internet of Things (IoT) possess the power to turn this vision into a reality. However, most organizations today are building their data infrastructure to focus solely on addressing immediate business needs vs. a platform capable of quickly adapting emerging technologies to address future ...
    SYS-CON Events announced today that Avere Systems, a leading provider of hybrid cloud enablement solutions, will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Avere Systems was created by file systems experts determined to reinvent storage by changing the way enterprises thought about and bought storage resources. With decades of experience behind the company’s founders, Avere got its ...
    SYS-CON Events announced today that Avere Systems, a leading provider of enterprise storage for the hybrid cloud, will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Avere delivers a more modern architectural approach to storage that doesn't require the overprovisioning of storage capacity to achieve performance, overspending on expensive storage media for inactive data or the overbui...
    SYS-CON Events announced today that IBM has been named “Diamond Sponsor” of SYS-CON's 21st Cloud Expo, which will take place on October 31 through November 2nd 2017 at the Santa Clara Convention Center in Santa Clara, California.
    SYS-CON Events announced today that Ryobi Systems will exhibit at the Japan External Trade Organization (JETRO) Pavilion at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Ryobi Systems Co., Ltd., as an information service company, specialized in business support for local governments and medical industry. We are challenging to achive the precision farming with AI. For more information, visit http:...
    High-velocity engineering teams are applying not only continuous delivery processes, but also lessons in experimentation from established leaders like Amazon, Netflix, and Facebook. These companies have made experimentation a foundation for their release processes, allowing them to try out major feature releases and redesigns within smaller groups before making them broadly available. In his session at 21st Cloud Expo, Brian Lucas, Senior Staff Engineer at Optimizely, will discuss how by using...
    In this strange new world where more and more power is drawn from business technology, companies are effectively straddling two paths on the road to innovation and transformation into digital enterprises. The first path is the heritage trail – with “legacy” technology forming the background. Here, extant technologies are transformed by core IT teams to provide more API-driven approaches. Legacy systems can restrict companies that are transitioning into digital enterprises. To truly become a lead...