PlanetMysql.ru — информация о СУБД MySQL

I chatted today about VMware's Cloud Foundry with Roger Bodamer, the EVP of products and technology at 10Gen. 10Gen's MongoDB is one of three back-ends (along with MySQL and Redis) supported from the start by Cloud Foundry.

If I understand Cloud Foundry and VMware's declared "Open PaaS" strategy, it should fill a gap in services. Suppose you are a developer who wants to loosen the bonds between your programs and the hardware they run on, for the sake of flexibility, fast ramp-up, or cost savings. Your choices are:

• An IaaS (Infrastructure as a Service) product, which hands you an emulation of bare metal where you run an appliance (which you may need to build up yourself) combining an operating system, application, and related services such as DNS, firewall, and a database.

  You can implement IaaS on your own hardware using a virtualization solution such as VMware's products, Azure, Eucalyptus, or RPM. Alternatively, you can rent space on a service such as Amazon's EC2 or Rackspace.

• A PaaS (Platform as a Service) product, which operates at a much higher level. A vendor such as handles all the back-end services and just exposes an API to which you program.

By now, the popular APIs for IaaS have been satisfactorily emulated so that you can move your application fairly easily from one vendor to another. Some APIs, notably OpenStack, were designed explicitly to eliminate the friction of moving an app and increase the competition in the IaaS space.

Until now, the PaaS situation was much more closed. VMware claims to do for PaaS what Eucalyptus and OpenStack want to do for IaaS. Vmware has a conventional cloud service called Cloud Foundry, but will offer the code under an open source license. Right Scale has already announced that you can use it to run a Cloud Foundry application on EC2. And a large site could run Cloud Foundry on its own hardware, just as it runs VMware.

Cloud Foundry is aggressively open middleware, offering a flexible way to administer applications with a variety of options on the top and bottom. As mentioned already, you can interact with MongoDB, MySQL, or Redis as your storage. (However, you have to use the particular API offered by each back-end; there is no common Cloud Foundry interface that can be translated to the chosen back end.) You can use Spring, Rails, or Node.js as your programming environment.

So open source Cloud Foundry may prove to be a step toward more openness in the cloud arena, as many people call for and I analyzed in a series of articles last year. VMware will, if the gamble pays off, gain more customers by hedging against lock-in and will sell its tools to those who host PaaS on their own servers. The success of the effort will depend on the robustness of the solution, ease of management, and the rate of adoption by programmers and sites.

PlanetMySQL Voting: Vote UP / Vote DOWN

This Friday at SCaLE 9x in Los Angeles, CA there will be a special build an open source cloud day teaching users how to use technologies from Cloud.com, OpenStack, Opscode and Zenoss to deploy, configure, manage and monitor infrastructure-as-a-service using open source software.

Here’s an overview of the program:

“Build a Cloud Day” will be dedicated to teaching users how to build and manage a cloud computing environment using free and open source software. The program is designed to expose attendees to the concepts and best practices around deploying cloud computing infrastructure. Attendees should expect to learn how to deploy a cloud computing environment using Cloudstack CE. In addition Build a Cloud Day attendees will learn about tools( Opscode Chef and Zenoss Core) that can be used to handle the dynamics of a cloud computing environment including automatic provisioning and configuration and monitoring.

---

9:00 – 9:15: Welcome – Mark Hinkle, VP of Community, Cloud.com

We’ll kick off the day reviewing the program with attendees and gathering information so we can tailor the program to best address the needs and experience level of the audience.

---

9:15 – 11:15: Build Your Private Cloud – Cloud.com

Using CloudStack Community Edition (CE), free and open source cloud computing software to build a private cloud. During the training attendees will be instructed on how to install Cloudstack CE to manage virtual infrastructure in a private cloud computing configuration. At the conclusion of the Build a Private section users will have the knowledge needed to create a simple private cloud network.

Cloudstack CE is an open source Infrastructure-as-a-Service (IaaS) software platform available under the GPLv3 license, which enables users to build, manage and deploy compute cloud environments. The community edition is based on the latest, leading edge features and bits that the Cloud.com team of engineers are working on and is supported by both our engineers and our open source community.

---

11:15-11:45: Openstack – Rackspace

OpenStack Deployment and Integration Engineer Jordan Rinke will give a brief overview of the Openstack project.

OpenStack is a collection of open source technologies delivering a
massively scalable cloud operating system. OpenStack is currently
developing two interrelated projects: OpenStack Compute and OpenStack Object Storage.
OpenStack Compute is software to provision and manage large groups of
virtual private servers, and OpenStack Object Storage is software for
creating redundant, scalable object storage using clusters of commodity
servers to store terabytes or even petabytes of data. OpenStack is sponsored by Rackspace, a leader in web hosting and managed infrastructure.

---

11:45 – 12:45: Lunch – Catered

We will bring in a simple catered lunch (We’ll do our best to accomadate all dietary restrictions).

---

12:45 – 2:45: Automatic Configuration of Your Cloud – Opscode

This training section will cover deploying cloud infrastructure automatically using Opscode Chef. We will be cover installation basics of Chef clients and working with a Chef server. Other topics will include: creating Chef repositories, writing cookbooks and advanced uses of the command line utility Knife.

Chef is a systems integration framework, built to bring the benefits of automated configuration management to your entire infrastructure. With Chef you can:

• Manage your servers by writing code, not by running commands.
• Dynamically integrate your applications, databases and other infrastructure.
• Easily configure applications that require knowledge about your entire infrastructure (“What systems are running my application?”, “What is the current master database server?”)

---

3:00 – 5:00: Monitoring Your Cloud – Zenoss

A representative from the Zenoss Core project will provide training on how to monitor a cloud computing environment. The presentation will give an overview of the Zenoss Core management platform. Attendees will also learn how to install Zenoss Core, add devices and send alerts based on conditions within your cloud computing infrastructure.

Zenoss Core is an open source IT monitoring product that delivers the functionality to effectively manage the configuration, health, performance of networks, servers and applications through a single, integrated software package.

All devices in the environment can be modeled – networks, servers, software, and applications – as well as custom devices such as power supplies and temperature sensors. The model provides logical and physical grouping allowing you to map devices to business systems, locations, and responsible people. The model is populated by the auto-discovery process, supplemented by the web services API, XML import/export, or manual user input.Collections of monitoring templates are called ZenPacks, and more than 100 are available.

5:00 -5:10 Special Guest – Arista Networks

Cloud architectures have changed the design requirements for high-performance networking infrastructure and a 100% Linux based, fully extensible networking solution can bring your Cloud to the next level. Arista Networks gives a 10-minute overview of the EOS Extensible Operating Systems and reviews some of the tricks of the trade that can make deploying, managing and maintaining a best-in-class network infrastructure easier than ever before.

Technorati Tags: cloud computing, cloud.com, opensource, OpenStack, Opscode

PlanetMySQL Voting: Vote UP / Vote DOWN

Over the past year or so I’ve found myself evaluating my overall programming experience with the languages I’m working with. I might just be getting impatient in my old age (turning the big three-oh in a couple months), but I like to think I’m trying to find the most efficient way to solve the problem at hand. This has led me to learn and experiment with a number of languages, taking a look at each one’s strengths and weaknesses. I realize programming language selection is very subjective and folks can get quite passionate in the debate, but I’m still going to present my personal opinions on the matter. Flame away.

The main question that I’m trying to try to answer is: What language will enable me to solve the problem at hand correctly and in the fastest way possible? By correctly I mean without bugs or missing requirements. By fastest I not only mean the initial design and coding phases, but also maintenance. I’m a strong believer that no piece of software is ever complete and is usually read many more times than it is written. An application needs to be written in a way that is easy to jump back into it after some period of time. I’ve considered a number of metrics while experimenting with each language to answer the above question and I’m going to touch on a few big ones before digging into various scenarios and languages. I should also prefix this with the assumption that I’m talking about community-driven open-source software. This can of course apply to any team, open or closed, but I don’t really care about those one-off programs that never leave your hard-drive. Here is a list of things to consider while evaluating your choices:

• Don’t be Different – Disregard all that hoopla about everyone being their own unique, beautiful butterfly – sometimes it’s best to conform. If I want to hack on the Linux kernel, I’m probably going to be doing it in C or assembly. If I want to contribute a plugin to Drupal or WordPress, it’s going to be in PHP. Even though it is technically possible to embed some other language into a project, it’s usually easiest to take the path of least resistance. There is only one work flow, one set of development tools, and less time spent context switching between the different languages. If there is some precedent for a language already, stop and use that. The rest of this post should be applied when you have a clean slate and can make choices without worrying about tight integration with an existing project.

• Be Mature – I recently read this article suggesting we need a new programming language, and while the ideas are nice, I can’t say I agree. As great as new languages like Go may be, you never know when the plug may be pulled on the core development team. There is always the option of maintaining the language tools as well as your project, but that’s a lot of extra work. I like to choose languages that I know are not going anywhere or won’t be changing too drastically in the future.

• Be Popular – There are a few websites out there that try to measure programming language popularity from various sources. Take them with a grain of salt, but it does give you a pretty good idea of who is hot or not, and even what the recent trends are. If a language doesn’t appear in the top 20-30 of the general lists, I usually don’t look any further. Google Trends can be useful as well to create your own trending graphs from their data set. Popularity is important because you want to have useful developer tools and a community to help answer your questions. If you and a professor at some university are the only people using a language, there is going to be a bottleneck on resources. This is also critical for open source projects when you want to build a developer community. Choose a language that folks already know so they can make useful contributions and help make your software better.

• Determine What’s Important – As with many aspect of computer science (and life), choosing a language is all about trade-offs. To make these decisions, you need to know what limits you are going to hit. Are you going to be bound by CPU, disk, network, user, or some other resource? By user bound I mean your application will always be limited by user interaction, and no hardware resource limits will ever be hit. If you are CPU bound, you probably want a machine code or efficient byte-code compiled language. If you are user bound, performance matters less so you have more options. Keep in mind these limits are not isolated and can have effects on one another. For example, some languages may make I/O interaction really easy at the cost of space, but this may be due to double or even triple buffering of data, causing your CPU usage to increase too.

• Don’t Guess – I found myself performing a number of micro-benchmarks to test various aspects of the languages. How long does it take to call a function? How much overhead is there in the concurrency primitives? How expensive is context switching? How efficient are the built-in string processing functions? It’s best to answer these questions by writing small programs in each language and comparing the results.

• Choose the Best Tool for the Job – Sometimes you choose a language mainly because it has a particular library, module, or some built in feature suitable for your application. Most languages have the same standard library bits, but many have a few niche uses and have great support for certain features. For example, if you’re going to be running on large multi-core machines and need to share a lot of memory between threads (so not multi-process), languages that have a single interpretor lock like Python may not be a good choice. If you want a simple, integrated webserver framework that you can customize, Python is great. C or C++ may not be the best choice in this case because you’ll mostly be writing your own. Examine what your primary feature requests are and how well they are met by each language.

My Current Preferences

Below is a list of a few classes of applications and my current preference for each. You’ll notice a lack of Java in the discussion, mainly because I’ve always been on the C++ side for object-oriented applications. I’d rather put the time into a C++/STL/boost application and eliminate the extra VM layer at runtime. C/C++ also has the benefit of being able to link with other C/C++ libraries natively, where in Java you would need to write a JNI wrapper, find the Java equivalent, or write your own native library.

• Web Applications – Early on I used Perl for all my web programming, then I switched to PHP for a number of years, and recently I’ve found myself preferring Python. It is a fantastic language and allows you to do almost anything with the objects at runtime (for better or worse). I’ve been doing some work on OpenStack and have found the WSGI standard great for building modular web applications. Combined with an event framework like Eventlet, you don’t even really need Apache httpd. The main concerns with Python are CPU bound tasks and SMP support because of the global interpretor lock (GIL). Most of the web apps I write are not bound by either and most of the heavy lifting (if any) is pushed to some other service that is more efficient (like a database). Projects like Django and Pylons take this to the next level providing frameworks around these basic ideas, but if you want to keep it simple then 10 lines of Python will get you a functioning web server and WSGI application (with a dependency on Eventlet). The Routes and SQL Alchemy packages also provide some very useful functionality while building your web applications.

• Scripting, Tools, and Middleware – For these types of apps, I’ve mainly used Perl or a combination of shell/sed/awk, but recently I’ve again found Python to be a better fit. Decent versions of Python are standard on any system now, so you don’t need to worry about customizing or installing any dependencies to get your applications running. Again, if there are SMP or CPU performance concerns, you might need to look at another language.

• Shared Libraries and Drivers – These consist of libraries that are used to provide some core functionality or other service. For example, libz for compression or libmysql to talk with MySQL servers. You really want the lowest common denominator so the library can easily be wrapped and reused in a number of other languages. This means writing it in C. Python, PHP, Perl, Erlang, Ruby, Lua, and pretty much all others have well defined interfaces for interacting with C libraries. Projects such as SWIG even take care of some of this interfacing work for you, allowing you to build multiple language bindings at once. You can of course write your driver in each language natively, but this can be a lot of work. You can probably get away with writing the library in C++, but you’ll most likely run into more issues than if you had just used C.

• Servers – This is where most of my time has gone throughout my career, and for about 10 years the answer was always C. I was always trying to squeeze every bit of CPU and memory out the servers I was writing. In the past three years I started doing a lot more C++ work for MySQL related projects like Drizzle, and recently I’ve been experimenting with a number of alternatives. In a previous blog post I tested performance and throughput for a few different solutions, and I while I was impressed with the higher level languages, the C++ version still won by a good margin. In further tests I performed more CPU-intensive calculations and the Javascript and Python versions went through the roof compared to C++. This was most likely due to less time being spent in the kernel for the I/O calls, which should be about the same regardless of language. There were two languages that did stand out in the performance tests: Go and Erlang. Even with heavier CPU loads, they both performed quite well, usually taking only 10-15% more time than the C or C++ equivalents. Go is still a no-go due to it’s immaturity, but I think Erlang is a real contender. I’ve been somewhat frustrated with C++ due to it’s verbosity and nuances. For example, defining and debugging complex template code can be a nightmare, but it’s required if you want to use the STL. When doing the same thing in Erlang, I found myself writing more concise code with less bugs in a fraction of the time. In other words, the code was almost as fast and much more elegant than the C or C++ equivalents.

And the winner is…

There is of course no single winner, choose the best tool for the job. I think the combination of C, Python, and Erlang are a good fit for a wide variety of applications. The mental shift to a functional language may take a bit in the case of Erlang, but I encourage you to give it a try if you have not already. The main downside of Erlang is its popularity (or lack thereof). It’s not too far down the list, but certainly not in the top ten. This is probably due to it being a functional language and not having a history of general purpose applications. The popularity of projects such as CouchDB and RabbitMQ are putting Erlang on the map and giving developers a reason to take a closer look. If you still need to squeeze every bit of CPU and memory out of your applications, you’ll probably need to stick with C or C++.

PlanetMySQL Voting: Vote UP / Vote DOWN

Josh Berkus gave a great talk at linux.conf.au 2010 (the CFP for linux.conf.au 2011 is open until August 7th) entitled “How to destroy your community” (lwn coverage). It was a simple, patented, 10 step program, finely homed over time to have maximum effect. Each step is simple and we can all name a dozen companies that have done at least three of them.

Simon Phipps this past week at OSCON talked about Open Source Continuity in practice – specifically mentioning some open source software projects that were at Sun but have since been abandoned by Oracle and different strategies you can put in place to ensure your software survives, and check lists for software you use to see if it will survive.

So what can you do to not destroy your community, but ensure you never get one to begin with?

Similar to destroying your community, you can just make it hard: “#1 is to make the project depend as much as possible on difficult tools.”

#1 A Contributor License Agreement and Copyright Assignment.

If you happen to be in the unfortunate situation of being employed, this means you get to talk to lawyers. While your employer may well have an excellent Open Source Contribution Policy that lets you hack on GPL software on nights and weekends without a problem – if you’re handing over all the rights to another company – there gets to be lawyer time.

Your 1hr of contribution has now just ballooned. You’re going to use up resources of your employer (hey, lawyers are not cheap), it’s going to suck up your work time talking to them, and if you can get away from this in under several hours over a few weeks, you’re doing amazingly well – especially if you work for a large company.

If you are the kind of person with strong moral convictions, this is a non-starter. It is completely valid to not want to waste your employers’ time and money for a weekend project.

People scratching their own itch, however small is how free software gets to be so awesome.

I think we got this almost right with OpenStack. If you compare the agreement to the Apache License, there’s so much common wording it ends up pretty much saying that you agree you are able to submit things to the project under the Apache license.  This (of course) makes the entire thing pretty redundant as if people are going to be dishonest about submitting things under the Apache licnese there’s no reason they’re not going to be dishonest and sign this too.

You could also never make it about people – just make it about your company.

#2 Make it all about the company, and never about the project

People are not going to show up, do free work for you to make your company big, huge and yourself rich.

People are self serving. They see software they want only a few patches away, they see software that serves their company only a few patches away. They see software that is an excellent starting point for something totally different.

I’m not sure why this is down at number three… it’s possibly the biggest one for danger signs that you’re going to destroy something that doesn’t even yet exist…

#3 Open Core

This pretty much automatically means that you’re not going to accept certain patches for reasons of increasing your own company’s short term profit. i.e. software is no longer judged on technical merits, but rather political ones.

There is enough politics in free software as it is, creating more is not a feature.

So when people ask me about how I think the OpenStack launch went, I really want people to know how amazing it can be to just not fuck it up to begin with. Initial damage is very, very hard to ever undo. The number of Open Source software projects originally coming out of a company that are long running, have a wide variety of contributors and survive the original company are much smaller than you think.

PostgreSQL has survived many companies coming and going around it, and is stronger than ever. MySQL only has a developer community around it almost in spite of the companies that have shepherded the project. With Drizzle I think we’ve been doing okay – I think we need to work on some things, but they’re more generic to teams of people working on software in general rather than anything to do with a company.

PlanetMySQL Voting: Vote UP / Vote DOWN

The past two weeks have been both exciting and extremely busy, first traveling to Austin, TX for the first OpenStack Design Summit, and then back home to Portland, OR for The O’Reilly Open Source Conference (OSCON) and Community Leadership Summit. The events were great in different ways, and there was some overlap with OpenStack since we announced it on the first day of OSCON and created quite a bit of buzz around the conference. I want to comment on a few things that came up during these two weeks.

New Role

I’m now focusing on OpenStack related projects at Rackspace. I’m no longer working on Drizzle, but I will still be involved in the MySQL and database ecosystems through future projects and conferences (see you at OpenSQL Camp). I will also still be working on a couple of Gearman related projects in my spare time. At OSCON I gave two presentations on Gearman and Drizzle, you can find the slides here.

The Five Steps to Open

One question that came up a few times over the past couple weeks is what the term “Open” means when a business or organization decides to adopt the open source philosophy. It turns out this means many different things to folks, and when an organization decides to go open, they need to make a decision on how open they are willing to be. Here are the various layers we’ve seen over the years:

• Open API – You’ve decided to take the first step to being open and released a well documented API to work with your web service or project. Everything behind the API is still a black-box though.
• Open Core – Beyond the APIs, you’ve decided to release part of the code open source, but you still keep some of the bits proprietary in an attempt to keep a competitive advantage. This is a hot debate lately on whether it is a viable Open Source business model.
• Open Source – You’ve decided keeping some code proprietary doesn’t help, and actually even hurts your project or adoption. You put all of the code out in the open for everyone to see. While everyone can see all of the source code, there still isn’t a whole lot of interaction going on.
• Open Development – Putting the source code out wasn’t enough. You want to enable users and external developers to be able to file bugs, submit patches, and track the development process to see what to expect next. This usually involves running your project on a public project site such as github or Launchpad.
• Open Decision Making – You’ve postponed the inevitable for long enough. Feature requests and bug reports are pouring in, and the community wants to have a say in what gets prioritized. Should we focus only on stability? Performance? New features? Porting to mobile platforms? Let the community decided the direction of the project.

There have been examples of success for organizations who have stopped at each of these steps. Given the proper environment, any can work. My preference is to work on projects that are fully open, where company and organizational boundaries do not exist between developers and users. I’m thrilled to say that we’ve gone all in with OpenStack. We’re hosted on Launchpad and have a governance structure that allows all parties within the community to have a say in the future of the project.

Preventing Vendor Lock-in

During the Cloud Summit at OSCON, there was a debate titled: “Are Open APIs Enough to Prevent Lock-in?”. Most folks came to the conclusion that the answer is “no,” and I agree. While I feel open APIs are necessary, they are by no means sufficient. Even if a project is open source and allows for open development, it probably will not prevent vendor lock-in. The key is to provide some incentive for vendors to adopt and invest resources within a project. Much like customers don’t want vendor lock-in when choosing a platform, vendors do not want project or feature lock-in when choosing the software to power their business. Each vendor who chooses to participate must have the ability to voice their opinion on the direction of APIs, features, and other project priorities. This is why it is critical that any open source project must take all the steps described above to give the project a chance of being adopted and becoming the de facto standard. There is of course no guarantee that adoption and prevention of vendor lock-in will happen, but I see them as necessary steps.

This is another area where OpenStack has done the correct thing. We are planning on having another developer summit in November, and then once every six months after that time. All design discussions and decision making will happen in public forums such as the mailing list and IRC. We want all participants in the community to have a chance to respond to topics being discussed, and we believe the more we have, the more successful the project will be. Having many voices allows the project to be more applicable to different environments. For example, Rackspace and NASA have different requirements for their compute architectures, but they also share many components as well. Through open participation we can ensure all needs are accounted for. Much like the LAMP stack has powered universities, governments, and competing business, we hope OpenStack can do the same.

Contributor License Agreement (CLA)

During the past couple of weeks a few folks asked what the CLA was all about. When the foundations of OpenStack were forming, the requirement of having a CLA came up from the legal side. Having been involved with open source projects that had very invasive CLAs, initially I had quite a bit of concern. The CLA is actually quite innocuous, and it does NOT require assignment or dual-ownership of copyright. You are the sole owner of code you contribute. For all intents and purposes it is a signed version of the Apache 2.0 license, the CLA just makes these terms more explicit. The CLA is handled through digital signatures, so no papers, pens, or faxing is required.

Get Involved!

Expect to see more posts on my blog related to OpenStack topics. If you would like to get involved, you can join the IRC channel (#openstack on irc.freenode.net), join the mailing list, or start contributing code! There are even jobs around OpenStack popping up already!

PlanetMySQL Voting: Vote UP / Vote DOWN