Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Actors as Microservices | @DevOpsSummit #DevOps #Microservices
Akka has rich semantics for specifying message delivery semantics

Actors as Microservices
By Nick Isaacs

Here at VictorOps, we rely heavily on Akka and during my time working with the environment/tool/language, I started seeing similarities between microservices and actors. Actors allow you to take pieces of your app, put them on their own servers and then enable them to communicate via HTTP. You can scale the app in places where there are bottlenecks and apply resources without being wasteful.

microservices_meme

Microservices are untyped (they communicate via JSON) however it is often the approach to write a client library on top of a JSON API, taking a weakly-typed interface and turning it into a more strongly-typed interface. Expanding on this idea, it is pretty easy to see how I made the jump of not thinking of actors as units of code but more like microservices.

Don’t believe me? A few other similarities…

– Both can be located anywhere in your infrastructure and communicate over TCP.

– Actors can happen to be running on the same boxes, or different boxes, but you know when you make a call, you expect a certain response.

– You can scale actors like you would scale microservices. Run actors over here on these computers and add or subtract boxes as you see fit.

– Actors, like microservices, are also weakly-typed. You can write client libraries that make it easier to consume API.

– Microservices and actors are subject to the same pitfalls. What happens if my service can’t be reached? What happens when things time out?

It’s like I’m using a microservice…
We already think of actors as services. Our team adopted a new paradigm: create an actor, write a library that allows for communication with that actor and then allow other people to use that library. By doing that, we have a more holistic view of how the actors should work, especially around the aspects of handling failure and ensuring you have a well-typed interface for communication.

Building Actor Interfaces
Below is an example of how we might write a typed interface for an actor. By interfacing with an actor through in a prescribed fashion we take the work of typing the responses off of the user, minimizing the possibility for error and reducing the time it takes for somebody to get up and running with the actor.

Message Guarantees
Akka has rich semantics for specifying message delivery semantics. Just like in the world of networked services, actor’s systems and clients can be built with at-most-once or at-least-once message delivery. In the example above, all messages are sent with at-most-once delivery. To guarantee at-least-once delivery of messages to actors, things get a little bit more complicated. Mixing in the AtLeastOnceDelivery into a PersistentActor gives the implementer the necessary tools to build in such messaging guarantees.

One challenge that we encountered trying to build in such guarantees was that we have built our own Zookeeper-based Akka cluster. As such, when a node goes down, there is no guarantee that its corresponding ActorPath will come back. This is a problem as the deliver() method in the AtLeastOnceDelivery method saves the corresponding ActorPath of the message when it is persisted.

We ended up using some sleight-of-hand to get around this requirement, which we believe to be an elegant way to allow maximum uptime of the delivering actor as well as retain its at-least-once semantics. What we did was to leverage the ability of actors to “become” a new state on message receive as well as the Akka resolveOne() method to asynchronously ensure that we have a valid ActorRef to send to. Once we know we have a valid ref, we can resend all un-confirmed messages to the new ref’s path; since the old path may never work again.

Another (naive) strategy to accomplish the same goal would be to block the actor in the preStart() method until the actor could resolve the path. This is not a great strategy however, because we can be accepting and persisting messages for sending later when the ref finally does resolve, as well as needlessly blocks a thread in the process.

Akka, and actors in general, are a fantastic way to build a scalable, fault-tolerant architecture because they put failure (in all its forms) at the forefront of the design decision. Thinking of these units of code as their own services takes this metaphor to the next level and pushes implementors to think more holistically, not only on the “happy path” of execution, but also how they scale and fail under less than ideal conditions.

The post Actors As Microservices appeared first on VictorOps.

Read the original blog entry...

About VictorOps Blog
VictorOps is making on-call suck less with the only collaborative alert management platform on the market.

With easy on-call scheduling management, a real-time incident timeline that gives you contextual relevance around your alerts and powerful reporting features that make post-mortems more effective, VictorOps helps your IT/DevOps team solve problems faster.

Latest Cloud Developer Stories
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that...
Adding public cloud resources to an existing application can be a daunting process. The tools that you currently use to manage the software and hardware outside the cloud aren’t always the best tools to efficiently grow into the cloud. All of the major configuration management to...
DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to ...
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions n...
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, mo...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



SYS-CON Featured Whitepapers
ADS BY GOOGLE