Blog

Capabilities of the Platform, Defined: Going Beyond Deploy & Scale (Part 2)

By Abraham Sultan10.3.13

This is the second part of a larger series I’m writing on ways in which the services of our platform reach beyond that of other PaaS vendors, who focus primarily on deploy & scale. My last blog talked about two ways we do so, by natively offering:

  • Caching Layer: A temporary data store that apps seek to leverage for a variety of reasons
  • Scheduling Services: A service that allows apps to schedule events to fire at specific points in time

The abilities of Apprenda’s PaaS that go beyond deploy & scale are not isolated solely to caching and scheduling, however. In this segment of my series I’d like to provide you with a few more examples of how our PaaS is best suited to meet the needs of the enterprise.

You Go Beyond Deploy & Scale? …Tell me more.

One of the important traits that help advance software development over the years is proper architecture patterns, and the Cloud is no different. That’s why Apprenda offers services to help developers in this area as well: Let’s talk about Queuing Services. Queues are queuewidely used in Cloud applications where messages can be put on a queue and later on read by another agent to service the request and remove it from the queue. Apprenda provides a native Multitenant Queuing System that is fully aware of the multi-tenant capabilities of the platform to help with this pattern; messages gain contextual information of the requesting customer, whose request invoked logic that placed the message on the queue. It’s highly powerful when writing SaaS apps because not only do you have the context of the queue, but you also have it of the customer or subscriber that was requesting the message itself that was placed there.

Another common architecture pattern amongst Cloud applications is pub/sub (publish & subscribe) where a client can publish and pubsubsubscribe to messages. For example, let’s say an application is made up of five modular components. Component 1 wants to notify anyone listening that something has happened. When a customer wants to do this, they would publish a message. People that care to know about that type of message would subscribe to it, and would be notified with a copy of that message each time an instance is published. This system allows a customer to have loosely coupled interactions with different components that subscribe to different events that they care to know about and a highly scalable manner. It’s a very typical architecture pattern that distributed apps leverage, and another service that our PaaS provides. Multi-tenancy, availability, and scalability of this type of service are only doable, however, if it is intimately brokered by the PaaS runtime.

Here’s an example that no other PaaS serves today: let’s talk Compliance

Say IT has a particular mandate that a specific library or DLL never be used, either because it poses a security risk or copyright infringement, or some other important compliance reason. Apprenda allows IT operators to set rules stating that if any app uses that library, it is to be prevented from being deployed. When devs are writing apps and testing them, they’ll realize instantly that they can’t be
complianceusing that specific library, and can stay within compliance without having to write the full app and being turned back at deployment time because this specific DLL wasn’t widely known during the development phase.

Another scenario, which has more to do with where an app can actually get deployed to, states that some apps have personally identifiable information (PII); because of different compliance rules, they need to reside on a specific set of hardware- hardware that needs to be controlled or maintained in different ways. A platform operator (IT) can define policy within the platform itself that says “any app that is marked with having PII needs to be deployed to this specified group of servers.” Perhaps that group of servers has been vetted by a security team to be managed and controlled in a secured fashion where PII can be hosted.

Apprenda allows operators to define rules on how apps can be deployed and ensure compliance. These rules are defined by the responsible IT teams and the platform simply applies them without any additional effort from the developers or operators.

Tag it and Bag it!

Basically- when a dev goes to deploy an app, they can mark it as having that information by setting a tag. IT can request that devs set the tag, or answer the question as to whether or not the app contains that personal information. If they don’t, the app can be deployed to tagwhatever server. If they do, though, there is a specific group of servers already established that can only host PII. This is another way the platform establishes and maintains compliance.

These are a few examples of different things Apprenda takes care of for you, so you can concentrate on building the applications and not running them. In my next installment I look closely at multitenancy, the differences between Isolated and Comingled models and the different layers of multitenancy offerings.

CTA_WP_Mobile_v1

Abraham Sultan

As VP of Engineering, Abe's focus is on setting the direction for the R&D organization at Apprenda. He spends his time evaluating and implementing Agile practices and evangelizing Cloud Technologies in particular Platform as a Service. Abe is also a frequent speaker at local meetup groups and enjoys networking at different Startup and Technology events. You can also follow him on Twitter at @asultan

2
View Comments

Leave a Reply

Your email address will not be published. Required fields are marked *