Hi,
Dne 01. 02. 19 v 14:10 Karol Bieniaszewski liviusliv...@poczta.onet.pl
[firebird-support] napsal(a):
>>> You completely misunderstood the announcement. The Firebird Butler is a
>>> thing that we develop.
>
> I am really interested if i am only one And because of this i am talking
> about any example as a first steep.
Well, if you read the list of services we plan to develop in first
round, you can imagine in how many ways they could be assembled together
to achieve various results. The point is, that Butler platform should
allow you to assemble them to work in single executable process, or in
set of separate processes that could be even distributed over multiple
nodes. The "container wrapping" should allow full customization.
How exactly these services would be created (features etc.) is not yet
determined. We certainly have our own plans and ideas, but we
deliberately opened the project before this was "carved in stone", so
others could get involved early with their own ideas and needs (so forks
or alternative versions are less likely to appear, as we don't want to
fragment the ecosystem from start).
If you want at least one real world use case, then imagine that you have
1000+ pharmacy shops and several HQ's in 5 countries with your
applications and Firebird servers & databases you have to manage
(backups, performance monitoring, failure detection & recovery,
including hw monitoring & management etc.). Picture yourself you have to
deal with such system 24x7. Then answer to yourself what you would need
to sleep tight at night? We (IBPhoenix) think that Butler would help us
and our customers sleep well.
But Butler is not just for big IT systems, it's designed to be equally
usable for small and personal solutions as well. Why do you think we put
so much importance to allow creation of single-process Butler apps in
our architecture? To allow easily deplorable custom builds/assemblies
for specific small and personal use. But our (IBPhoenix) personal
interests are more at the high end.
>>> Steam-like deployment platform for Butler services provided by Firebird
>
> Ok, than is this as a distribution platform for „small” services or what?
Personally (as Python Butler SDK lead developer), I would like create a
deployment platform for Butler services that would allow users to
download and install Python Butler services from shared repository and
run them in custom configured containers. We could then have deployment
"recipes" tailored for specific tasks that would download, install,
configure and run services, instead having specifically tailored binary
distributions. If you are familiar with Python, then picture something
like PyPI & pip + paste combined. I don't know what plans exactly others
have with their versions (Java, Pascal), we will see what they come
with. Eventually the Firebird Project would like to host a repository of
Butler services for direct deployment for all "language kits". But that
is more distant future. After all, Python, Java and Pascal have very
different distribution & deployment methods. However, the point is that
services created in different languages can work together as they are.
Any deployment or integration "platform" is just nice simplification of
deployment that could be always done by hand.
>>> So far, there is no single line of code available to public that you
> could use
>
> Do you think that this was too early announced especially on support group
> then?
> Normally i am real enthusiast of „new” ideas especially in products which i
> use, but without exaple hmm...
Well, firebird-support list is one from most visited Firebird
communication channels. We thought that such announcement is worth to
send here as well.
>>> But either REST or Widnows services are NOT good enough for IBPhoenix
>>> purposes
>
> Can you extend this sentence, especially why?
> What is in this planning „Butler” what is better?
> This description can bring more light on the purpose.
Well, do you think...
- that http is best and most efficient method of communication between
services, especially between ones that may live also in the same
executable / process? We need "elastic" effectivity, i.e. squeeze as
much as possible from each specific deployment environment and scenario.
- that http+REST is good for asynchronous communication between
services? We need async, sync would be nice sometimes but not essential.
- that REST API is more message oriented than interface oriented? Our
experience is that interface oriented approach while easier to cope with
is a show killer in too many situations.
- that REST API is easy and most effective way how to assemble multiple
services together in any non-trivial manner without extensive custom
glue code? We want to avoid glue code as much as possible, declarative
approach is better for us, especially when dealing with 100+ copies of
the similar yet not exactly the same.
- that Windows
