ODP: ODP: ODP: [firebird-support] Re: Introducing Firebird Butler
Thank you Pavel for explanation. Now i see what is the key point of this „platform” and it is promissing. >> - 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. Comunication between servises especially on the same server, no. There are faster ways to talk beetween 😉 >> - that Windows services are viable solution for Linux, Mac and other >> platforms? We are multiplatform shop. This was only sample what is easy to do and available superfast. And i have thinked only about service gettering messages and storing into Firebird database. But as you described now, this is a different story and this is only some portion of the whole base services. Regards, Karol Bieniaszewski
Re: ODP: ODP: [firebird-support] Re: Introducing Firebird Butler
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 serv
ODP: ODP: [firebird-support] Re: Introducing Firebird Butler
>>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. >> Steam-like deployment platform for Butler services provided by Firebird Ok, than is this as a distribution platform for „small” services or what? >> 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... >> 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. regards, Karol Bieniaszewski
Re: ODP: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 01. 02. 19 v 8:04 Karol Bieniaszewski liviusliv...@poczta.onet.pl [firebird-support] napsal(a): > > If you or someone can show me (and maybe others are also interested) any real > benefit, example, than i am more than interested in this. > And i am not only interested in using it, but i then can offer time to > implement something. You completely misunderstood the announcement. The Firebird Butler is a thing that we develop. It's a joined effort primarily driven by IBPhoenix and IBSurgeon as part of Firebird Project (these companies are currently the main drivers, but others are welcome) initiated by their internal need and in scope of mutual interests with Firebird Project they are part of. It's done as open source so everyone could benefit from our joined effort, but it's not developed for our or public entertainment or without business angle that makes sense for those involved. It's designed as it's designed because it makes sense for those involved, it solves (or should solve) problems they face. So far, there is no single line of code available to public that you could use. Although IBPhoenix (and IBSurgeon as well) has wagons of various internal tools and code for many Firebird-related and other purposes, they are not (yet) adapted to Butler architecture. Anyway we have a neat pool of code and proven ideas to draw from to move forward quickly once the SDK(s) would be ready. Anyone is welcome to watch what we will do (the easiest way is to sign-up for Butler list(s), and watch Butler web and git repositories). If you will see a value in what we will do, you are free to use it, or join our effort if you want to have an influence on where its going. Also, new ideas and questions are welcome at appropriate place and in proper form. Usual open source business. However, at current state of affairs, it's a time for architects and designers who see potential in our selected approach and would like to participate on such thing to step in and share ideas at Butler list. Once first SDK would be ready, no much space would be left to introduce completely new ideas or designs (that one would like to try or needs) to see it implemented. Once SDK(s) would be ready, anyone is welcome to play with it to see how it could be used for their own purposes. That same apply when first services we have in our plan would be provided. However, if anyone wants to have something we plan to do earlier or to have influence what would be implemented and how, the best option is to get involved in a way and to the extent that would suit their needs. I.e. open source business as usual. > But without real introduction i will stay with REST/Windows services based on > Delphi. > Thay work for me for e.g. IOT with big traffic and any problems. You are welcome to use whatever you see fit for your purposes. But either REST or Widnows services are NOT good enough for IBPhoenix purposes (I could not speak for others). best regards Pavel Cisar IBPhoenix
Re: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 31. 01. 19 v 20:54 blackfalconsoftw...@outlook.com [firebird-support] napsal(a): > II... > My understanding of the Firebird Butler project could be two-fold... > A specification for best practices for developing distributed systems using > the Firebird Database Engine A set of enterprise tools to implement such > systems (ie: an equivalent to Windows Communication Foundtaion: hence the > attribution to ZeroMQ Just my thoughts... Well, one could call a Framework as "best practices" enforcement tool :-) Although Butler SDK is not a typical framework. If you would draw a parallel to WWW, then Butler specifications are like HTTP and related specifications, Butler SDK's are frameworks and libraries to create services that use these specifications (like there are ones for www technologies), and Butler itself (the product(s)) are applications assembled from these services like web servers, browsers etc. Because it's a LEGO system, it's not a single application, but rather a "distribution" (in Linux sense) or a "delivery platform" (like Steam). Both approaches are possible. Over time, we would like get to the Steam-like deployment platform for Butler services provided by Firebird Project as preferred over purpose-tailored distributions, but it's an open ecosystem, so anyone could do what they want regardless to our preferences. The Firebird Project will create services needed to manage Firebird server deployments (as first goal for Butler product, see description of our plan), but we will not stop there (for example we plan to recreate our internal QA test system as Butler app [set of QA services]). Others could use Butler specifications and SDK's to integrate their applications with services provided by us or other entities as they see fit, or could use Butler applications provided by us and others "as is". Or create their own services/applications for whatever purpose, even not related to Firebird in any way. Does it make more sense now? best regards Pavel Cisar IBPhoenix
Re: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 31. 01. 19 v 21:05 blackfalconsoftw...@outlook.com [firebird-support] napsal(a): > > Has anyone considered using ZeroC's Ice Framework? Ice is classic RPC framework with all its limits and drawbacks. We think that RPC is wrong abstraction model to create dynamic heterogeneous systems. The abstraction model of our choice is pure message passing between "objects" (services), not interfaces, hence the reason we chose ZeroMQ. > It appears to be a much more finished product with better diocumentation > than ZeroMQ and is completely Open Source... ZeroMQ is not less "finished" than Ice, it's also open source and documentation is quite solid (although not that fancy). The differences is "quality" you percept are caused by fact that Ice is "corporate open source", while ZeroMQ is "community open source". In this regard you could say that MySQL is more finished product with better documentation than Firebird. best regards Pavel Cisar IBPhoenix
ODP: [firebird-support] Re: Introducing Firebird Butler
Thank you to be involved into discussion. But i am still oposite. Example do not required any unique description. Example is not less/more than only shortcut to description. It is introduction to description. Description can talk about example or will be totally unreleated. But example is comparable to sentence „one image is better than thousand of words”. If i understand correctly this „Introducing Firebird Butler”. I better see this not as something „blown” and based on something external to Firebird. If i can propose somthing in this matter, then maybe Firebird engine should have some additional listen port. On that port firebird listen on incomming traffic in simple REST messaging like JSON. On Firebird side we can declare some specific trigger which can consume such JSON or whatever. But if we think about services build for Firebird than, think how simple is to write e.g. Windows Service in Delphi. How easy is to write and PROTECT! REST service in Delphi. Do you suppose that someone will be build such service in this „Introducing Firebird Butler”? Are you sure that someone will be reading virtual documentation without seeing simple example at start? Without knowing anything about benefits compared to simple Windows Service or REST service? If you or someone can show me (and maybe others are also interested) any real benefit, example, than i am more than interested in this. And i am not only interested in using it, but i then can offer time to implement something. But without real introduction i will stay with REST/Windows services based on Delphi. Thay work for me for e.g. IOT with big traffic and any problems. regards, Karol Bieniaszewski
[firebird-support] Re: Introducing Firebird Butler
Just a question about the use of ZeroMQ... Has anyone considered using ZeroC's Ice Framework? It appears to be a much more finished product with better diocumentation than ZeroMQ and is completely Open Source... Steve Naidamast Sr. Software Engineer
[firebird-support] Re: Introducing Firebird Butler
I have two comments on this thread... I... The examples provided (I & II) do not necessarily show a correct pattern of either. In the first example, the assumption can be made that the description is unique and thus requires a unique example. The second is merely a reverse of the first, as a unique example requires a unique description. Where the second pattern example fails is when you can have multiple examples of the same concept, thus requiring basically a single description. For example here are two examples of adding to an integer variable in C#... CIntVar = CIntVar + 1 CIntVar++ Both examples would only need a single description, which describes that there are several ways to increment an integer variable in C#; the first using plus(+) operator, the second using the plus-plus(++) operator. II... My understanding of the Firebird Butler project could be two-fold... A specification for best practices for developing distributed systems using the Firebird Database Engine A set of enterprise tools to implement such systems (ie: an equivalent to Windows Communication Foundtaion: hence the attribution to ZeroMQ Just my thoughts... Steve Naidamast Sr. Software Engineer blackfalconsoftw...@outlook.com