Hi, Dne 01. 02. 19 v 14:10 Karol Bieniaszewski [email protected] [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 services are viable solution for Linux, Mac and other platforms? We are multiplatform shop. best regards Pavel Cisar IBPhoenix
