Appserviceschat

interoperability. and treating services as attached

A1) Developers need a standard way to connect to any service from any app on any platform using any marketplace. No vertical lock-in by framework.

Unless you enjoy reimplementing technologies over and over, standard interfaces matter.

ease of use for app developers! Focus on business function - not services!

Let's avoid reinventing the wheel!

because services!

It offers a standardized approach to attaching services to a platform.

Standardizing service delivery across platforms is better for the industry at large.

make it will make it easier for producers to expose their services to other platforms

A1) differentiation and innovation are to be commended...except when it results in multiple interfaces

@Jay_Judkowitz precisely - who wants to have to do this for every possible platform their service might need to integrate

cross platform service inter-operability!

Consistent model for provisioning backing services across multiple platforms.

Does standardizing service delivery platforms run the risk of standardizing services?

@sogrady has it right. Nobody likes to invent the same thing over and over again!

@tmmoore_1 exactly, here's my user story: as a developer, I want to be lazy

@SMFulton3 It's about standardizing discovery, provisioning, and binding to services, not standardizing the services themselves.

@Jay_Judkowitz @SMFulton3 you can envision that over time some services may commoditize

@tmmoore_1 And new services will evolve as app requirements change.

amount of learning developers have to do creating the services

data related services

isn't that like asking which of your children is your favorite?

A2) historically, core infrastructure (compute, storage, etc). increasingly, higher level services (DB, PaaS, etc).

A2) Data services. Also, anything hosted outsied your app platform, e.g. sending mail.

@christo4ferris So maybe the question for you is which cloud service is your least favorite?

@sogrady in the context of services to directly support an application, it seems to be some sort of RDBMS, some key-value store, some message bus, then other "stuff"

OH: It's whoever has the best sticker @cloudfoundry

A2 - the correct answer is the one your application needs

A2) general purpose services such as DB, analytics, and messaging...but also internal domain/org-specific services

@chipchilders: agreed. s/RDBMS/RDBMS *and* multiple other DB styles/.

today traditional RDBMS services, future messaging / event services

@DevinDavis the one that isn't using the Open Service Broker API

data services +1 and messaging queue - this is a bare minimum that most of the customers use. For data services it is usually relational, key-value, and caching

A6) having one interface to target is far more manageable for non-tech companies than one per provider

@sogrady bingo! give that man a kewpie doll

A6) the reduction in friction towards opening services means that more of them will become available

1:M is the way to go

writing a service broker is quite simple, they can then run it on a cloud platform or self-host. The broker can then be registered to the marketplace of any Open SB API supporting platform provider.

A standardized API allows "non-tech" companies to easily expose more of their services, internally and externally.

A6) those that wish to have their own service catalog gain interoperability across platforms as well

@tmmoore_1Agreed, cross-platform services allows for better workload portability.

+1. Very exciting use of the API.

Is a service catalog a prerequisite for using a service broker?

details about SIG mtgs & slack channels here: https://github.com/k...

yea, its sort of the coordinator of the system for the platform

provides the indirection/abstraction for you

Props to @cheddarmint for deftly sneaking a plug in for service catalog!!! (This is the droid I'm looking for!)

@SMFulton3 the catalog is basically the integration between the platform and the broker API.

this shows that the Open Service Broker API promise of cross-platform service brokering is starting to happen!

@SMFulton3 I wouldn't say it's an absolute prereq, but I wouldn't want to use brokers without a nice catalog to organize services for me and my whole org

@AlexEvade Yeah, I think this is really awesome. Consider the alternative of everyone building their own thing. That would be terrible. Better to cooperate and get economy of effort!

@SMFulton3 @bradtopol the marketplace aspect to the catalog model gives developers (platform users) a one stop shop.