2017년 1월 17일 화요일

Binary Messaging formats emerging

The widespread use of ASCII encoding formats like JSON and rest may be killing server performance. A wide variety of emerging binary formats offer significantly improved performance for processing messages. This could be particularly important for I/O intensive applications like transaction processing, data analytics, and financial services.
The server-side recently spoke with Martin Thompson, founder of software consultancy Real Logic about the merits of binary encoding formats for message processing. He said, “I've seen many applications that spend significantly more CPU time parsing and transforming XML and JSON than executing business logic.”

Message parsing gains

This in particularly important in the finance industry, where applications need to be able to process market feeds that can peak at over 10 million messages per second, and are continuing to grow. The financial industry ratified the SBE binary messaging for processing financial data and transactions designed to dramatically reduce the latency compared with alternatives.

Thompson worked with a team to develop a reference implementation of SBE in Java, C++, and C# that was able to process about to process about 34,000 messages per second, or about 16-25 times faster than Google Protocol Buffers (GPB ) on the same hardware. This in turn was over a thousand times quicker then what can be achieved with JSON.

Achieving this level of efficiency is not for the faint of heart. Thompson said that the resulting application had to be debugged using the Wireshark protocol analyzer, rather than the built-in debugging tools in Java IDEs. This of course begs the question of whether more efficient binary formats that reduce CPU and networking bandwidth are worth the trade-off of increased developer bandwidth and a longer software development lifecycle.

Many binary messaging formats emerging

A number of different binary messaging formats have emerged over the last couple of years including the finance industry’s Fast Protocol, Google Protocol Buffers, Apache Avro, Facebook’s Thrift, and Microsoft Bond. All of these different formats promise increased efficiency compared with ASCII encoding formats like JSON and XML.

Adopting them can improve the throughput of almost any application involved in message processing. They also promise to reduce the power requirements in IoT devices, said Thompson. These messaging formats also show promise ingesting data from the rising tide of IoT devices now being deployed.

What holding back binary messaging?

At the same time these formats have not been widely adopted by the developer community outside of finance. One part of the challenge might be that JSON fits in well with the Java development paradigm. These other encoding formats require developers to stretch their thinking around application development. They may also make it harder to document an API in a way that is accessible to third-party developers. This could be a deal breaker for enterprises that work with a larger developer community that integrate the API into their applications.

Another factor holding back adoption may be that the performance gains are just not significant enough compared to other components of an application’s performance. If a particular application is more constrained by compute or memory limitations, a more efficient messaging protocol will not be as important. Enterprises would also have to consider how to shift their development tooling and train developers to get the most from these new protocols.

In some ways, it’s surprising that enterprises are starting to adopt less performance development languages like JavaScript and Python. But this makes a lot of sense when developer attention becomes a scarcer resource. Futurist George Gilder once opined that the best business models waste the eras cheapest resources in order to conserve the era’s most expensive resources. As the cost of cloud services goes the cost of an efficient application development lifecycle becomes more important. Thus, some start to finish. Businesses may want to wait until these binary messaging alternatives become cheaper to integrate into modern applications.

from The Serverside.com

Simple Binary Encoding (SBE)

SBE is an OSI layer 6 presentation for encoding/decoding messages in binary format to support low-latency applications. The SBE project on GitHub is the reference implementation for the FIX SBE standard for the encoding of financial messages.

SBE provides a compiler for taking a message schema and generating stubs for messaging parsing in multiple languages. Currently Java, C++, and C# (courtesy of Adaptive) are supported. SBE allows allows for the on-the-fly decoding of messages from a compiler generated meta description. Details for using SBE can be found on the Wiki.

Performance is a key requirement for SBE. Performance with consideration to throughput and latency of encoding/decoding binary messages exchanged via a local area network (LAN) of servers which typically have x86 processors. For example, the transmission of financial orders and market data in a co-located environment.

The design follows a number of principles and makes no compromise by adding features that violate these principles. You may find that alternative codecs, such as Protocol Buffers, offer more features. Features such as allowing strings at any location in a message. SBE only allows variable length fields to come at the end of a repeating group or message. SBE makes some restrictions in return for more than an order of magnitude increase in throughput at very low, and importantly, predictable latency.

To get started with with SBE please read the Wiki and then get the latest at:
  • Java: Maven Central
  • C++: building from source

source: https://github.com/real-logic/simple-binary-encoding

Google protocol buffers


Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

  • are simpler
  • are 3 to 10 times smaller
  • are 20 to 100 times faster
  • are less ambiguous

generate data access classes that are easier to use programmatically

When this message is encoded to the protocol buffer binary format (the text format above is just a convenient human-readable representation for debugging and editing), it would probably be 28 bytes long and take around 100-200 nanoseconds to parse. The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse.


Introducing proto3
Protocol Buffers language version 3 (aka proto3), as well as some new features in our existing language version (aka proto2). Proto3 simplifies the protocol buffer language, both for ease of use and to make it available in a wider range of programming languages: our current release lets you generate protocol buffer code in Java, C++, Python, Java Lite, Ruby, JavaScript, Objective-C, and C#. In addition you can generate proto3 code for Go using the latest Go protoc plugin, available from the golang/protobuf Github repository. More languages are in the pipeline.

-- from developers.google.com

2017년 1월 16일 월요일

Java Microservice

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
- martinfowler.com


Java microservices advantages
The main advantage of microservices architecture is simpler application design and administration. Because microservices break a complex set of operations down into discrete parts, they make it easy for developers and admins to make changes to one part of the application without affecting other parts or requiring the entire application to be restarted.

Java microservices can also provide some security benefits. When the different parts of an application are isolated from one another, an attacker who is able to gain control of one service does not gain control of the entire application.

This security isolation can be especially useful in use cases like the Web application described above. In that case, the data storage system would remain safe in the event that an attacker compromises the public-facing application front-end.


Why use Java microservices?
So, what’s making microservices popular all of a sudden now, and how are microservices different than SOA? To answer those questions, let’s first examine the advantages of microservices, then take a look at how two other current trends, DevOps and Docker, make microservices more advantageous than SOA.


Java microservices versus SOA
To Java developers who were around about ten ago, the microservices approach to application design probably sounds familiar. In many ways, the Java microservices paradigm is similar to Service-Oriented Architecture, or SOA. SOA, which was popular in the 2000s, also emphasized the division of complex applications into discrete services. That communicate via APIs.

SOA enjoyed some popularity, but it never revolutionized the way applications were designed. The SOA fad faded after a few years, and monolithic applications remained common.


Java microservices, DevOps and Docker
Microservices complements some other trends that are changing the way developers write and deploy software. In particular, the DevOps trend that began in the late 2000s is driving renewed interest in microservices, which help to make software delivery more modular and efficient.

In addition, the introduction several years ago of Docker containers gave developers a new, easier way of building microservices. With Docker, you can run each service inside a container, and combine those containers to compose a complex application.

Docker makes it easier to create and manage a microservices application than the old SOA paradigm allowed. With Docker, once your services have been Dockerized so that they can run in containers, you can deploy those containers to any server with Docker installed. You can also move them around between hosts for portability. And you can use container orchestration tools for automatic provisioning.

- from the serverside.com

Which Mobile App Development Option is Better?

Different alternatives to native code development have their own advantages and philosophy behind. No one tool or approach can be clearly ma...